こんにちは私は小さなプロジェクトを設計しようとしています。データアクセス、ビジネスサービス、WcfService、UIレイヤーを計画しています。
EF4.0とMVC2.0を使用しようとしています。私の質問は、EFを介してエンティティとObjectContextをどこで生成するかです。最初はDataAccessで計画しました。ただし、すべてのレイヤーでエンティティを使用できるようにするには、すべてのレイヤーでDataAccess dllを参照する必要があります（これは適切なアプローチではありません）。
エンティティと呼ばれる新しいレイヤーでエンティティを作成し、DAにObjectContextを残すことはできますか？それがどれだけうまくいくか。
エンティティとPOCOの基本的な違いは？（両方ともEFによって生成される必要があります）。
これらのエンティティは、デフォルトでDataContract（Seralized）として使用できますか？
コードをできるだけ繰り返さないようにしています。これがどのように機能するか教えてください。
ありがとう
NerdDinnerと呼ばれる「実際の」サンプルアプリケーションと、CodePlexでの185ページのPDFウォークスルー「how-each-line-was-written」をご覧になることをお勧めします。
実行中のアプリはここにあります：http：//www.nerddinner.com/
NerdDinnerは、小規模なプロジェクトに適している必要があります。より複雑なソリューションのオーバーヘッドを大幅に節約できます。それ以外の場合は、レイヤー間にDTOオブジェクトを導入し、AutoMapperを使用してありふれた「property-by-property-copy」コードを減らすことができます。
ビジネスロジックは、データアクセスから完全に分離する必要があります。あなたが正しく言ったように、データアクセスのすべてのレイヤー間で共通のオブジェクトを渡すことは悪いことです。
しかし、エンティティのように（コード生成で）POCOを作成するにはどうすればよいですか？
私は、ビジネスロジックは、物事が概念的に「始まる」場所であるという観点から取り組んでいます。ドメインモデルを具体化すると言うこともかなり正確でしょう。
POCOは、情報を渡す方法です。ほとんどの場合、POCOの設計は、ビジネスロジック（またはドメインモデル）のニーズによって決定されます。ドメインモデル/DDDの考え方の場合、POCOはそのドメインの一部である可能性があります（現時点では、それが問題であるかどうかはまだわかりません）。
つまり、それらが（概念的に）どのように生成されるかは、ビジネスロジックのニーズによるものです。ただし、パフォーマンスが要件の重要な側面である場合は、パフォーマンス関連の問題（多くの個別の呼び出しではなく、1つの大きなDTOに大量のデータを戻すなど）によって引き起こされるものもある可能性があります。
それらはどのように物理的に生成されますか？ええと、私はそれらを手で書くか、一緒にハッキングした小さなツールを使って書きます。Structs私はPOCOに（および）を使用する傾向がありCollectionsますが、代わりに使用することもできますclasses。
いくつかの理由から、ビジネスロジックまたはドメインモデルから自動的に生成することを検討していません。