正常的教科书3层应用应该看起来像
数据访问 – >业务逻辑 – >演示
演示文稿不应该知道有关数据访问的任何内容.使用EF,所有层都需要了解模型.所以我的架构现在看起来更像
Data Access->Business Logic
| |
---------------
|
MVC
我在这里缺少某些东西,还是以错误的方式思考？
我应该把EF本身作为数据访问层,把实体放在业务逻辑中吗？
解决方法
看看这个简单的架构,我用它为我的MVC应用程序,它似乎是干净,高效的.
>解决方案中的项目 – 业务模型 – 简单的类库,包含代表业务领域的POCO类.您可以在这里使用数据注释,元数据类用于验证逻辑等.
>项目 – 基于EF的存储库 – 另一个简单的类库;这里是定义的上下文(EF代码首先是好的,但是您可以先使用EF数据库或者首先使用 – 您只需将POCO T4模板添加到业务模型类库中即可),并设置类 – 存储库
>项目 – 我通常称之为“ServiceLayer”(我打开建议更好的名称:) – 它只包含接口,存储库和其他服务(在单独的项目中实现),我的MVC(或任何其他技术)基于应用的使用;来自2.project的存储库实现这些接口
>项目 – MVC网站.它使用依赖注入(构建在DependencyResolver中,我喜欢使用Ninject容器)来映射存储库(和其他服务);那么你可以使用构造函数注入控制器,或者一些“懒惰”方法(见下文)
看起来像这样：
瘦控制器：
public class SomethingController : BaseController
{
public ActionResult DoSomething(SomeBusinessThing input)
{
if (ModelState.IsValid)
{
var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input);
return View(result); // you can use AutoMapper here,if you dont want to use business object as viewmodels
}
}
}
我的存储库“属性”继承自我的BaseController：
public class BaseController : Controller
{
// ... other stuff used by all (or multiple) controllers
private ICustomerRepository _customerRepository;
protected ICustomerRepository CustomerRepository
{
get
{
if (_customerRepository== null)
_customerRepository= DependencyResolver.Current.GetService();
return _customerRepository;
}
}
}
你可以使用这个“懒惰”DI,如果您的控制器使用许多服务,但每个动作只有1-2个,所以使用构造函数注入它们将是一种效率低下.有人可以告诉你这是“隐藏”的依赖,但如果你把所有这些东西放在一个地方 – BaseController,它没有什么大不了的.
那么,仓库的实现真的是你的事情. MVC应用程序甚至不知道您正在使用EF,它只知道服务接口,并不关心底层实现(如果需要,您可以随时切换)！
联盟：
>控制器是瘦的 – 没有业务逻辑>模型是FAT – 在这种情况下,存储库封装了所有的业务逻辑(您也可以确定使用其他类型的服务,例如一些计算器用于处理等等,请记住,MVC不关心,只知道接口)> viewmodels是为视图输入的(viewmodel可以直接作为您的业务模型,也可以使用AutoMapper创建“纯”viewmodels)
