public SomeService : ISomeService
{
ISomeRepository someRepository;
public Do(int id)
{
someRepository.Do(id);
}
}
所以这有点多余
所以我开始直接在控制器中使用存储库
这个可以吗 ？是否有一些架构正在这样做？
@R_301_323@
You lose the ability to have business logic in between.
我不同意这一点.
如果业务逻辑应该在哪里 – 在域模型中,那么在控制器中调用repo(或者更好 – 使用模型绑定器)来获取聚合根和调用方法对我来说似乎完全没问题.
当涉及太多技术细节时,应该使用应用程序服务,这会弄乱控制器.
I’ve seen several people mention using model binders to call into a repo lately. Where is this crazy idea coming from?
我相信我们在这里谈论两件不同的事情.我怀疑你的’模型绑定器’意味着同时使用模型作为视图模型,并将UI中的更改值直接绑定到它(这本身并不是坏事,在某些情况下我会走这条路).
我的’模型绑定器’是一个实现’IModelBinder‘的类,它在构造函数中占用存储库(因为我们需要使用一些基本组合进行缓存,因此可以扩展)并在调用操作之前使用它来检索聚合根和用实域对象替换int id或Guid id或string slug或任何action参数.将它与输入视图模型参数相结合,可以让我们编写更少的代码.像这样的东西：
public ActionResult ChangeCustomerAddress
(Customer c,ChangeCustomerAddressInput inp){
c.ChangeCustomerAddress(inp.NewAddress);
return RedirectToAction("Details",new{inp.Id});
}
在我的实际代码中,它有点复杂,因为它包含ModelState验证和一些可能从域模型内部抛出的异常处理(提取到Controller扩展方法中以便重用).但不多.到目前为止 – 最长的控制器动作是~10行长.
你可以看到工作实现(非常复杂和(对我来说)不必要的复杂)here.
Are you just doing CRUD apps with Linq To sql or trying something with real domain logic?
正如你可以(希望)看到的那样,这种方法实际上几乎迫使我们转向task based app而不是基于CRUD的应用程序.
By doing all data access in your service layer and using IOC you can gain lots of benefits of AOP like invisible caching,transaction management,and easy composition of components that I can’t imagine you get with model binders.
…并且有一个新的抽象层,它邀请我们将基础设施与域逻辑混合在一起并失去域模型的隔离.
Please enlighten me.
我不确定我是否这样做过.我不认为我自己开悟了. 原文链接：https://www.f2er.com/aspnet/251977.html
