我正在创建一个包含这三个不同项目的应用程序:
ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)
ApiService
提到BusinessLogic
BusinessLogic
提到DataAccess
DataAccess
使用实体框架和代码优先方法,因此它包含数据库表的模型。
我的问题是,有关商业和服务项目模型的最佳方法或最佳实践是什么?
我已经读过服务项目不应该使用DataAccess
项目的模型,那么我应该在服务中还是在商业中创建模型?
提前致谢。
始终从BL(Business logic)/Presentation layer
模型中分离出DAL(Data access layer)
模型。
在它们之间添加一个将执行映射的图层,使用Automapper或somethogn custom。因此,当您将数据传递给DAL
时,模型将映射到实体模型,当BL
从DAL
same获取数据时,将实体模型映射到BL
模型,
为什么?
您在数据库中保存数据的方式可能与您向用户呈现数据的方式有很大不同。数据可能必须从几个实体获得,通过关系连接,在运行时通过从其他表连接再构建,等等。您将如何向用户呈现它可能会简化并与持久化不同,因此您可以隐藏数据库所需的复杂性。
我不知道这是否是最佳实践,但我已经制作了许多项目,其中包含Windows服务,Web API等之间的许多共享逻辑和功能。它们都遵循类似于此的内容:
包装器 - 包含接口,模型和代码,以便更轻松地从另一个.NET项目调用Web API。根本没有参考其他项目
核心 - 包含所有丰富的业务逻辑。服务层,数据访问层,帮助程序类等。引用包装器和其他任何需要运行的东西
Web API - 仅包含围绕服务层功能创建Web API所需的代码,用于模型/接口的Core References Wrapper和用于业务逻辑的Core
使用Core的其他项目与WebAPI类似。示例是用于计划任务的控制台应用程序,用于连续数据处理的Windows服务等。
这导致我看到一些人称之为“大型解决方案”或类似的东西,但只要您将代码保留在一个域中,就不会造成混乱。