私のプロジェクトの1つでEntity Framework 4.1を使用しています。エンティティモデルはどこにありますか?
このソリューションには、モデルとリポジトリを含む7つのプロジェクトがあります。私はすでにデータベースを持っているので、私はデータベースファーストアプローチを使用してPOCOモデルオブジェクトを作成しています。
エンティティモデルと自動生成されたエンティティクラスがモデルプロジェクトまたはリポジトリプロジェクトにあるのが理にかなっていますか?
私のプロジェクトの1つでEntity Framework 4.1を使用しています。エンティティモデルはどこにありますか?
このソリューションには、モデルとリポジトリを含む7つのプロジェクトがあります。私はすでにデータベースを持っているので、私はデータベースファーストアプローチを使用してPOCOモデルオブジェクトを作成しています。
エンティティモデルと自動生成されたエンティティクラスがモデルプロジェクトまたはリポジトリプロジェクトにあるのが理にかなっていますか?
本当にあなたがEF4.1に依存していることが幸せであるかどうかによって異なります。
純粋にデータアクセスのものなら、リポジトリ。これは、あなたのPOCOが意図的に不要な依存関係を取り除いていることと、レイヤ間で渡されるデータ構造であることを前提としています。
編集
だから、あなたは責任と依存関係を考える必要があります。
Scott Millett(または誰でも)が7つのプロジェクトを思いついたとき、彼らはそれぞれが何をしているのかを述べましたか?彼らがそうした場合、これはあなたの答えの少なくとも一部を与えるべきです:あなたがEFがあなたのために(またはあなたがそれを使用しようとしているものについて)それぞれのプロジェクトの目的とは何かについて考えるならば。
ただちに明らかにならないことの1つは、ビジネスロジックが存在する場所です。私はそれがモデルだと仮定しています。ビジネスロジックに関することは、あなたが潜在的にそれをたくさん再利用したいということです。あなたがそれを再利用するときには、再利用のコンテキストが現在のものと異なる可能性があります。
これらの異なるコンテキストには、技術的な制約が非常に異なる可能性があります。そのような場合は、依存関係の可能性を最小限に抑えたいことがあります。あなたが何か(EFのような)に頼っているときは、それが依存するものにも依存します。 EFモデルがSQLに依存している場合(たとえば、)、ロジックはSQLに結び付けられます。
また、自動生成は問題になる可能性があります。何かを自動生成しないと決めた場合は、
個人的には、レイヤ間を渡すために私自身のPOCOを工夫し、純粋にリポジトリ内でEFを使用する傾向があります。
このようなものには絶対的な答えはないと私は理解しています。私はレイヤー間にこれらのデータ構造を渡すことを計画していたので、Modelプロジェクトが最も適していると思いました。どう思いますか? – mob1lejunkie
他にどのような層がありますか?あなたのソリューションには7つのプロジェクトがあります。それらは "ビジネス"層か "ロジック"層ですか? –
私はコントローラ、インフラストラクチャ、モデル、リポジトリ、サービス、Services.Cache、およびUI.Webを持っています。私はScott MillettのプロフェッショナルASP.NET Design Patternsブックからこのデザインを得ました。 – mob1lejunkie