デカップリングをすべて実行すると、DataAccessレイヤをモデルから分離する必要があります。しかし、その後、面倒になり、データアクセス層に情報を渡す...代わりに：MVC asp.net - データアクセス層とドメインモデルの結合を解除する必要がありますか？
void Save(myModel modelObject) {
//db.Save here
}
私は
void Save(string objectprop1,objectprop2...) {
}
を行いますと、それは単純化の目的を敗北ではないでしょうか？
モデルをデータアクセス層に渡すと完全にクリーンなコードになりますが、デカップルされていないと思います。
あなたのデータアクセス層は、あなたのドメインモデルについて確かに知っているはずです。あなたは、それらを数え切れないほどの原始的な議論に分解することは非常に悪いことだと思うのは正しいです。
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はそれらを使用するバックエンドの実装です。