Entity フレームワークの使用について、友人と少し話し合いました。エンティティ フレームワークをデータレイヤーとして使用して 3 層ソリューションを作成し、データ転送オブジェクトを使用してビジネス層からユーザー インターフェイスに移行するプロジェクトがありました。後で hibernate などを使用してエンティティ フレームワークを変更できるため、それが提供する疎結合が本当に気に入りました。一方、私の友人は、Entity フレームワークの目的は、ユーザー インターフェイスで使用できるようにモデル化することであると主張していました。エンティティ フレームワークをソリューションにどのように結合しますか?
1 に答える
2
私の友人がHibernateとEFの交換可能なレイヤーを提案しているという考えはわかりますが、これら2つのフレームワークにはすでにDL-> BL機能が含まれているため、少し抜本的だと思います。EFやHibernateのようなフレームワークを使用する理由は、優先順位に従って次のとおりだと思います
。1.ビジネスロジックでのエンティティの直接使用
2.データベースタイプの独立性
3.自動キャッシュ4.SQL
抽象化
このようなフレームワークも層に緩く結合されていると予想すると、現実にはならない可能性のある互換性を補うために、クエリの解析、オブジェクトのラッピングとアンラッピング、およびさまざまなノイズが必要になります。私が見ているように、彼の提案は次のようになります：
DL-> DL-> BL-> UL
誰かがこれに同意しますか？
于 2009-04-24T10:10:04.887 に答える