5

C＃で標準の3層アプリケーションを構築しています

1フロントエンド用のコンソールアプリ/ただし、これをASP.NETMVCWebページに変更する可能性があります

2ビジネスロジック層

3SQLデータベースに接続されたEntityFrameworkを使用するデータレイヤー/ただし、これはWindowsAzureに変更される可能性があります

主な目的は、いくつかの顧客データを表示することです。

データベースに保存されている顧客には、次のフィールドがあります-

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Creationdate
Updatedate
IsDisabled //this represents "deleted" customers i.e. the app will never use deleted customers, but I want to keep them in the database anyway

中間層では、私は欲しいだけです

CustomerID
Firstname
Lastname
DateOfBirth
Othervalue1
Othervalue2
Othervalue3
Updatedate

そして、最初のアプリケーションのフロントエンドでは、

CustomerID
Firstname
Lastname
DateOfBirth

データレイヤーから顧客をロードし（変更される可能性があります）、その顧客を中間層で使用し、次にプレゼンテーション層で使用する（変更される可能性があります）という観点から、n層アプリを適切に実装するにはどうすればよいですか？

顧客モデルはどこに置きますか？複数必要ですか？どこかにICustomerインターフェースが必要ですか？

プロジェクトの詳細 プロジェクトは2つのチームによって開発されます。1つは米国にあり、もう1つは東ヨーロッパにあり、4〜5人のチームメンバーがいます。

このプロジェクトでは使用されないレガシーデータアクセス層があります。代わりに、EntityFrameworkを使用して新しいものを構築します。すべての新しいアプリケーションで使用されるデータレイヤーを設計および構築する必要があります（このアプリでは、customerテーブルと1つまたは2つのテーブルのみが必要です）。他のプロジェクトは、このレイヤーに他のテーブルを追加します。

DIを使用してICustomerRepositoryを注入しています（このSOの質問を参照してください）。ただし、リポジトリと作業単位のパターンを実装します。

私の懸念は、レイヤーを適切に分離することです。今後数か月で多くの新しいプロジェクトを追加し、新しいデータレイヤーは急速に成長します。また、ある時点でAzureへの移行も検討しているため、ビジネスレイヤーとフロントエンドレイヤーを書き直さなくても、EntityFrameworkデータレイヤーをスワップアウトできるようにしたいと考えています。

4

1 に答える 1

6

データモデル（DBスキーマ）、ドメインモデル、およびビューモデルがあります。

レイヤーを分離することが目標である場合は、これら3つのレイヤーのそれぞれにCustomerを表す個別のクラスが必要です（ただし、コメントで@Joeが言及している記事を参照してください）。

データアクセステクノロジーは、データモデルからドメインモデルへのマッピングを推進します。Entity Frameworkを使用する場合、これら2つのモデル間でマッピングする機能が提供されます。

ドメインモデルをビューモデルにマッピングするには、ドメインオブジェクト（ビジネスオブジェクトなど）とビューモデルの間のマッピングについてAutomapperを参照してください。

アップデート

あなたの新しい情報に基づいて、私が何をするかを共有します。それは確かに唯一の有効なアプローチではありません。

チームが分散していることを考えると、明確な責任範囲が重要です。さまざまなタイムゾーンで、さまざまなチームリーダーを持つさまざまな人々が、コードに取り組んでいます。

レガシーデータベースに基づいて構築されている新しいソフトウェアを考えると、次の3つの事実に注意する必要があります。

  • 新しいソフトウェアのニーズに対応するためにレガシーデータベースを変更することは容易ではありません。
  • 新しいソフトウェアは、既存のデータベースの構造のために、次善の設計を内在させるべきではありません。
  • 現在のアプリケーションの設計を汚染するデータは、次に作成するアプリケーションで必要になる場合があります。

私は次のことをします

  • レガシーデータベースの構造を表すデータ転送オブジェクト（DTO）を作成します。
  • リポジトリーと作業単位パターンを使用して、ビジネス・オブジェクト層のDTOへのアクセスを提供します。
  • そのアプリケーションのニーズに応じて、ビジネスオブジェクトレイヤー（クラスがエンティティと呼ばれることが多い中間層）を設計します。DTOの構造（最終的にはレガシーDBの構造）に基づいてオブジェクト設計を汚染しないでください。
  • Automapperなどのテクノロジーを使用して、これら2つのレイヤー間のマッピングの配管作業を容易にします。
  • 特定のUI画面（MVC用語で表示）が処理するデータを表すUIオブジェクト（MVC用語ではモデルと呼ばれる）を作成します。
  • UIモデルがビジネスオブジェクト（エンティティ）とどの程度一致しているかに応じて、Automapperを使用することも、カスタムコードでそれらを設定することもできます。

繰り返しになりますが、私の経歴、経験、好みを考えれば、それが私がそれにアプローチする方法です。有効なアプローチはこれだけではありません。

于 2013-02-10T01:25:07.143 に答える