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