1

asp .net アプリケーションに Entity Framework 4.0 を使用しようとしています。今のところ、古いスタイルのコード ビハインド ファイルで単体テストはありませんが、将来的には MVP と単体テストを使用する可能性がありますが、現時点では問題ありません。データベースファーストのアプローチを使用しています。これがモデルです（画像を投稿するには評判が必要なため、画像を投稿できませんでした）

  • 表: アプリケーション (ApplicationID、名前、非表示)
  • 表: ユーザー (UserID、ApplicationID、Username、IsActive)
  • 表: ロール (RoleID、ApplicationID、Name)
  • 表: UserRole (UserRoleID、RoleID、UserID)

私はEntity Frameworkとその使用方法について多くのことを読んできましたが、それでもいくつかのことについて非常に基本的な考えを得ることができませんでした. Application、User、Role、UserRole などのコードはどこに記述すればよいですか?

public List<Application> GetAllUnhiddenApplications()
{
    List<Application> applist = null;
    using (CustomAppsPortalEntities ctx = new CustomAppsPortalEntities())
    {
        applist = (from app in ctx.Applications
            where app.Hidden == false
            orderby app.Name
            select app).ToList();
    }
    return applist;
}

Context と Entities を別々のプロジェクト Project.Data と Project.Entities にそれぞれ分けました。私の質問は、上記のコードが BLL (クラス名 ApplicationBLL) または DLL (ApplicationDLL) に属しているかどうかです。過去 2 日間から、私は多くの SO の質問、ブログ、チュートリアルを検索してきましたが、さまざまな人がさまざまなアプローチをとっています。これが私のジレンマです。

コードをデータ レイヤーに配置した場合、ビジネス レイヤーでは、ApplicationBLL.GetAllUnhiddenApplications のような "パス スルー" 関数を作成する必要があります。この関数は、ApplidationDLL.GetAllUnhiddenApplications を返します。すべてのクエリに対してそれを繰り返す必要があり、基本的に BLL 全体が最終的に DLL の「パススルー」レイヤーになります。上記のスキーマを参照して、どのようなビジネス レイヤが使用されるかの具体例を教えてください。

コードをビジネスレイヤーに配置すると、ビジネスレイヤーにlinqが存在し、最終的にEntity FrameworkによってSQLに変換されるため、クエリロジックをビジネスレイヤーに公開するようなものです。

私たちの環境 私たちの環境はペースが速く、別のレイヤーがある適度に適切なアプローチでこのプロジェクトをできるだけ早く完了したいと考えていますが、将来時間があれば、コードをリファクタリングして本当に堅牢にするかもしれませんが、現時点では問題ではありませんが、時間が許せば、将来的にコードをリファクタリングするのではなく、今すぐベスト プラクティスを実装したいと考えています。

4

2 に答える 2

0

上記のコードは通常、BL レイヤーにあります。BL レイヤーで linq を使用することは問題ありません。これは、linq クエリがまだデータの永続性を認識していないためです。linq クエリの観点からは、エンティティ フレームワークからオブジェクトをクエリしています。

不足している可能性があるのは、「リポジトリ パターン」と「作業単位パターン」です。リポジトリ パターンは、エンティティ フレームワークへのインターフェイスとして機能します。これにより、メモリ内コレクションなどの EF オブジェクトを操作できます。通常、すべてのリポジトリを 1 つのプロジェクトに保持し、それに応じて参照します。例を挙げると、Microsoft スペインは n 層の例を提供しています。

http://microsoftnlayerapp.codeplex.com/

それは非常に過剰に設計されていますが、あなたが探しているものを提供すると信じています.

于 2013-10-20T21:27:35.477 に答える
0

多くの人々は、EF は DLL であると主張しています。

通常、私は自分のプロジェクトを次のように設定します...

  D --->  Presentation Layers (MVC, WCF, WinForms, etc)
  A               |     
  T               V
  A --->  Business Logic Layer
                  |
  M               V
  O --->  Entity Layer / DLL
  D
  E
  L

Data Models プロジェクトは、他のプロジェクトで使用できる POCO の単なるコレクションです。

エンティティ レイヤーは、EDMX ファイルとコンテキストです。

.Net によってすべてが抽象化されているため、エンティティ/DLL 層のコンテキストにアクセスしても問題ありません。

考えてみれば、DLL 層を抽象化する全体的な理由は、BLL を変更せずにデータベースを変更できるようにするためです。EF を使用すると、データベースを 1 ステップで変更でき、スキーマが同じままである限り、すべてが機能するはずです。

于 2013-10-20T21:39:50.543 に答える