使用存储库模式,如何在不创建泄漏抽象的情况下引用域模型

本文关键字:抽象的 泄漏 创建 情况下 引用 模型 存储 模式 | 更新日期: 2023-09-27 17:59:54

设置

NET、C#、WebAPI、实体框架使用代码优先迁移

摘要

我正在设计一个。NET解决方案。存储库位于堆栈的底部,目前包含我的域模型。我在存储库(例如BLL)的顶部有层,最后在堆栈的顶部有一个API层,其中包含我的RESTful API端点。

以下是当前解决方案堆栈的简化伪图:

-API-BLL-储存库

问题

在API层中,我希望使用。NET的ModelState验证。问题是,这需要API层具有对存储库层的引用(ergo知识)这不是一个漏洞百出的抽象吗

使用数据传输对象似乎是解决方案,但这似乎很愚蠢,因为它们与存储库中的域模型基本相同。这不允许太多抽象。

另一种选择

我正在考虑添加一个单独的项目来包含域模型,然后允许API、BLL和Repository引用该项目。有什么理由不这样做吗?

我在这里看到的唯一缺点是,现在我的解决方案中的三个项目将需要访问数据库:

  • API(因为我在API中设置了OWIN身份验证)
  • 存储库
  • DomainModels(因为我使用的是代码优先迁移)

感谢您的帮助。

使用存储库模式,如何在不创建泄漏抽象的情况下引用域模型

存储库位于我的堆栈底部,当前包含我的域模型

这就是您的问题,存储库使用域实体,但它不包含它们。repo是持久性的一部分,您的域模型应该是domain层的一部分。repo接口也是Domain的一部分。

因此,您的域模型(作为一个概念)应该与您的持久性模型不同,即您在EF中使用的pocos来做CRUD的事情。域对象是根据业务视图建模的,持久性pocos的设计考虑到了数据库的使用(存储/易于查询)。

域层应该是核心,持久性和应用程序服务应该使用它,即依赖它。你可以看看洋葱架构或业务组件/垂直切片(这是一种更先进的方法IMO)