3 層アーキテクチャを使用している ASP.net (C#) プロジェクトがあります。DAL で Entity Framework を使い始めましたが、Entity Framework によって生成されたクラスをビジネス ロジック層でどの程度使用できるかという問題があります。
それらを直接使用することをお勧めしますか、それとも独自のビジネス オブジェクトを作成し、Entity Framework (db->O/RM->BO) からそれらにマップする必要がありますか?
3 層アーキテクチャを使用している ASP.net (C#) プロジェクトがあります。DAL で Entity Framework を使い始めましたが、Entity Framework によって生成されたクラスをビジネス ロジック層でどの程度使用できるかという問題があります。
それらを直接使用することをお勧めしますか、それとも独自のビジネス オブジェクトを作成し、Entity Framework (db->O/RM->BO) からそれらにマップする必要がありますか?
私の意見では、EF オブジェクトはあなたのものにマップされます。これには開発コストがかかりますが、持続性の無視と分離という追加の利点があります。このデカップリングは、企業が別の永続化ソリューションに切り替える必要がある場合に、長期的には大幅な俊敏性と実際の節約につながる可能性があります。デカップリングを行わないと、EF オブジェクトが BLL やプレゼンテーション レイヤーに深く埋め込まれ、大規模なリファクタリングが必要になる可能性があります。このような場合、ビジネスは持続性ソリューションの切り替えを検討することさえできない可能性があり、ビジネスの競争力が低下する可能性があります。
より高い開発コストでこのメリットを享受するかどうかの決定は、ビジネスが受け入れるリスクの量に依存します。プロジェクト コミッショナーと相談し、最善の判断を下して、彼らの戦略的目標を技術的な方法で解釈することをお勧めします。
生成されたクラスをビジネス オブジェクトとして使用するのは十分合理的です。生成されたクラスは部分的であるため、必要に応じて簡単に拡張できます。ただし、インターフェースを使用する方が良い場合もあります。
私はEF 2.0(.Net 4.0ベータ2)を使い始めたばかりで、POCOクラスをEFエンティティとして使用する機能があります。つまり、EF 2 で永続性を無視したクラスを使用できる
ようになりました。Visual Studio 2010 ベータ 2 で作業しているときに PDC 2009 のプレゼンテーションに従うことができなかったので、これはまだ完全には準備ができていないと思いますが、ADO でこれに注意してください。ネットチームブログ.
EntityFramework用のPersistenceIgnorance(POCO)アダプターを確認することをお勧めします。これは、EF1.0にPOCOサポートをもたらすEFチームのメンバーによるオープンソースプロジェクトです。EF 4.0は、すぐに使用できるPOCOサポートを備えていますが、このプロジェクトは、2010年に.NET4.0がリリースされるまでの一時的な対策として機能します。