我有一个使用 NHibernate 和 ASP.Net MVC 的项目。该应用程序旨在允许用户跟踪某些数据,然后根据输入的数据生成统计视图。到目前为止,我的应用程序的结构如下所示:
NHibernate 层:包含Repository<T>
和UnitOfWork
类,以及实体映射定义。
核心/服务层:包含通用EntityService
类。目前,这只是通过IUnitOfWork
接口定义事务范围,IRepository
以提供更高级别的数据访问服务。
表示层(MVC 应用程序):尚未实现,但包含通常的东西加上依赖注入。
我有一些问题:
允许我的 MVC 应用程序处理所有层的依赖注入是糟糕的设计吗?例如,除了将
EntityService
实例依赖注入到控制器中,它还将处理依赖注入IRepository
到EntityService
类中。服务层是否应该自己处理这个问题,即使这意味着在两个不同的地方执行依赖注入?我应该在哪里生成我的统计数据?这个业务逻辑似乎不属于我的服务层,目前它只包含实体类型定义和一个用于修改和访问实体属性的接口。我对此有一些想法,但我不确定我最喜欢哪个:
- 保持我的服务层不变并创建一个单独的统计项目 - 这完全独立于将要使用的实体类型,这意味着我的 MVC 控制器将必须在我的业务实体和我的(可能是静态的)统计数据之间传递原始数字信息类。这是一个非常巧妙的分离,但可能意味着大量业务逻辑仍保留在表示层中。
- 创建一个统计项目;但是,在这个项目中的类和我的业务实体之间创建一个紧密耦合。例如,我不会将
Reading
对象的值传递给方法,而是传递整个对象(或将它们定义为扩展方法)。这会将业务逻辑从我的 MVC 应用程序中移出,但紧密耦合似乎有点混乱。 - 将我的所有业务逻辑保留在我的服务层中。定义 的强类型子类
EntityService
,因此我的服务既包含特定于实体的业务方法,也包含数据存储方法,同时将实体类本身保持为纯数据容器。为任何通用统计处理创建一个单独的统计项目,并通过我的派生服务类调用其方法。我的服务类有效地将业务功能与IRepository<T>
.
我对第三种选择犯了错误,但有人有什么想法吗?替代建议?
提前致谢!