2016-05-18 20 views
0

私はドメイン階層に、階層的な方法で複数のレコード(テーブル行に対応)を含むFormオブジェクトを持っています。これらのレコードにはフィールド(そのテーブルの列)があります。アプリケーションユーザは、フィールドを更新し、フォームからレコードを追加/削除することができます。フォームオブジェクトのこの公開APIは、フォームの検証ルールを起動します。データベースオブジェクトをドメインオブジェクトにロードするための内部メソッドの使用

しかし、データベース値をフォームオブジェクトにロードするにはどうすればよいですか?データアクセスレイヤーはドメインレイヤーを認識しているので、自分のドメインオブジェクトに内部メソッドを作成する必要がありますか?そのため、サービスレイヤー(ドメインの最上位に位置する)がデータアクセスレイヤーにフォームオブジェクトを要求すると、データアクセスレイヤーはそれらの内部メソッドを使用して必要なドメインオブジェクトを作成できます。

public class DEForm 
{ 
    public DEForm(FormNumber number){} 

    public AddRecord(RecordNumber to, string type) { // do some validation here} 

    internal AddExisting(Record record, RecordNumber to){} 
} 

申し訳ありませんが、これは初心者の質問かもしれません。私はアプリケーションの設計に多くの経験がありません。情報が混乱している場合はお知らせください。詳細を追加します。

ありがとうございました。

+0

あなたが何をしているのか分かっていれば、既にデータベースがあり、フレームワーク経由でデータを出し入れする方法が必要ですか?私はここをクリックします[Entity Framework](https://msdn.microsoft.com/en-us/data/ef.aspx) –

+0

はい。すでにデータベースとデータアクセスコードが書かれています。私たちはコードを整理しようとしています。私たちのUI、ドメイン、BL、DALはすべて非常に緊密に結合されています。 – vabii

答えて

0

あなたが求めていることを達成するためのパターンがいくつかあります。私がコメントしたり、ここにリストしたりするつもりはなく、私が普段使っているパターンの概要を説明しています。

下位層は、データのソースリポジトリです。これは、データベース、Webサービス、WCFサービス、エンタープライズサービスバス、または何でもかまいません。ドメインオブジェクトを生成するために必要なデータを取得します。

次のティアアップは、データアクセス層とドメインオブジェクトで構成されています。私のデザインでは、ドメインオブジェクトは愚かです。それらは単にデータコンテナです。データアクセス層は、データアクセスオブジェクト(DAO)からなる。これらのオブジェクトは、データソースを照会し、必要なドメインオブジェクトにデータを設定します。各ドメインオブジェクトには、固有のDAOがあります。

DAOはそれぞれ、メソッドFetch、FetchList、Insert、InsertList、Update、UpdateList、Delete、およびDeleteListを提供します。内部的には、FetchメソッドはTransformと呼ばれるプライベートメソッドを使用します。Transformは、データソースがデータベースの場合はDataReaderからレコードをパラメータとして取り、適切なドメインオブジェクトを返します。

次の層はリポジトリ層です。この層は、DAOを使用して複合オブジェクト(データオブジェクトと子オブジェクトを含むオブジェクト)を作成/維持します。

次の層は、ビジネスルールを適用するオブジェクトを持つビジネス層です。

次の層はサービス層です。このレイヤーは、インターフェイスレイヤーでデータを使用できるようにします。

インターフェイスレイヤは、プレゼンテーション(UIベースアプリケーション用)または公開インターフェイス(Webサービス、WCFサービスなど)です。

私はこれが「正しい」または「ベスト」パターンであると主張していません。それは私が使用するパターンです。

+0

したがって、ドメインオブジェクトには、DAO /リポジトリとビジネスレイヤの両方で使用できるパブリックゲッターとセッターがあります。しかし、ビジネスレイヤーは検証を実行し、UIレイヤーはそのレイヤーを認識します。そうですか? – vabii

+0

UIレイヤーだけがサービスレイヤーに直接アクセスできる点を除いて、右です。サービスレイヤは、ビジネスレイヤを認識します。 – Kevin

+0

ありがとうございます。それは理にかなっている。 – vabii

0

カプセル化を維持するには、ビジネスレイヤのオブジェクトが外部から作成されないようにする必要があります。すなわち、BLの外側からnewDEFormになることはできません。これは、オブジェクトの作成ルールがBLのみによって強制されることを保証するためです。データアクセスレイヤーからのデータでオブジェクトを水和させたい場合は、データアクセスレイヤー(またはブリッジクラス)が呼び出すファクトリ(たとえばDEFormFactory)を公開します。

または、Entity FrameworkなどのORMを使用できます。

+0

しかし、工場は公共のものでなければなりません。また、工場では、内部のAddExistingメソッドを使用して水和する必要があります。内部のAddExistingメソッドが公開されていない場合は、リフレクションを使用する必要があります。 – vabii

+0

ビジネスオブジェクトを作成する必要があり、インスタンス化のルールをカプセル化しているので、ファクトリを公開することもできます。したがって、反射を使用する必要はありません。 –

+0

データアクセスレイヤー、ドメインレイヤー、およびサービスレイヤーが別々のプロジェクトであるため、この疑問があるのは私が推測する理由です。私はDALとDomainだけがAddExistingメソッドにアクセスできると考えていました。おそらく、私はあまりにも多くを制御しようとしています。 – vabii

関連する問題