MVC asp.net - 数据访问层是否应该与域模型解耦？

发布于 2024-12-15 16:14:04 字数 296 浏览 5 评论 0原文

如果我一直遵循解耦，那么数据访问层似乎应该与模型解耦。但随后将信息传递到数据访问层就变得很麻烦......而不是：

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

我会这样做，

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

这难道不会违背简单性的目的吗？

我认为将模型传递到我的数据访问层是完全干净的代码，但它并没有解耦。

原文

If I follow decoupling all the way, it would appear that DataAccess layer should be de-coupled from models. But then passing the information to the data access layer becomes cumbersome...Instead of:

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

I will do

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

Wouldn't that defeat the purpose of simplicity?

I think that passing a model to my data access layer is perfectly clean code, but then it's not de-coupled.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

天生の放荡 2024-12-22 16:14:04

您的数据访问层当然应该了解您的域模型。您的想法是正确的，将它们分解为无数的原始参数将是一件非常糟糕的事情。

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 是使用它们的后端实现。

Your data access layer should certainly know about your domain models. You're right in thinking that breaking them apart into untold numbers of primitive arguments would be a very bad thing.

De-coupling the DAL doesn't mean removing the dependency of the models from the DAL, but rather removing the dependency of the DAL from the models. The DAL can be represented, for example, by simple repositories:

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

Or something of that nature, there are many ways to design it. The idea here is that the DAL is then free to store things in a different structure than the models represent. But from the perspective of the models, they're just persisting to repositories. The actual data persistence may be a different table structure (optimizing the database for performance without having to change the business models as a side-effect, for example) or even in multiple databases entirely.

There's nothing wrong with the DAL knowing about the domain models. Indeed, as part of the domain, the DAL is expected to know about it. The models are central, the DAL is a back-end implementation which uses them.

回复收藏 0 原文

~没有更多了~