1

デカップリングを最後まで行うと、DataAccess レイヤーをモデルからデカップリングする必要があるように見えます。しかし、その後、情報をデータアクセスレイヤーに渡すのは面倒になります...代わりに:

void Save(myModel modelObject) {
//db.Save here
}

やります

void Save(string objectprop1,objectprop2...) {
}

それは単純化の目的を無効にしないでしょうか?

モデルをデータ アクセス レイヤーに渡すことは完全にクリーンなコードだと思いますが、分離されていません。

4

1 に答える 1

3

データ アクセス層は、ドメイン モデルについて確実に認識している必要があります。それらを無数のプリミティブ引数に分割することは非常に悪いことだと考えているのは正しいです。

DAL の分離は、DAL からモデルの依存関係を削除することを意味するのではなく、モデルから DAL の依存関係を削除することを意味します。DAL は、たとえば、単純なリポジトリで表すことができます。

interface Repository<TModel> where TModel : BaseModel
{
    TModel Get(int id);
    IEnumerable<Tmodel> Get();
    void Delete(int id);
    TModel Save(TModel model);
}

またはその性質の何か、それを設計する方法はたくさんあります。ここでの考え方は、DAL はモデルが表すものとは異なる構造に自由に格納できるということです。しかし、モデルの観点からは、それらはリポジトリに永続化されているだけです。実際のデータの永続性は、別のテーブル構造 (たとえば、副作用としてビジネス モデルを変更する必要なくデータベースのパフォーマンスを最適化する) であったり、複数のデータベース全体であったりする場合があります。

ドメイン モデルを認識している DAL に問題はありません。実際、ドメインの一部として、DAL はそれについて知ることが期待されています。モデルは中心的であり、DAL はモデルを使用するバックエンド実装です。

于 2011-11-15T00:17:33.047 に答える