我正在阅读有关服务层和存储库的信息。现在,我想知道服务层是否必须包装dal。我正在处理存储库和MVP模式。演示者现在拥有业务逻辑。但是,我考虑得越多,将业务逻辑放在演示者或数据访问层中都不是逻辑的地方。这就是服务层进入的重点。
但是,主持人现在是否在与服务层对话?主持人可以“允许”访问存储库吗?还是应该一切都通过服务层?在后一种情况下,服务层只是一个中间人:
MyFooService:
public List<Foo> GetAllFoo()
{
var listFoo = new FooRepository().GetAll().TiList();
return listFoo;
}
主持人:
public List<Foo> GetAllFoo()
{
var listFoo = new MyFooService().GetAllFoo();
return listFoo;
}
是好的方法吗?还是“允许”演示者直接调用存储库?
最佳答案
有时,您不需要过度设计,也不需要在不需要时将其强制为模式。
DAL本身就是一种访问数据的特殊服务。
通常,您的服务层将执行与您的数据不直接相关的任务。考虑诸如PaymentService,AnalyticsService之类的事情,可以将它们分解成可重用的组件。
假设您需要在所有社交媒体上分享一个帖子,您可以将其添加到一项服务中,该服务可以登录正确的社交媒体并发布:
MySocialBlastService : ISocialService
{
void ShareToTwitter() { }
void ShareToFacebook(){ }
}
现在,从您的控制器/演示者可以调用此服务。
public ActionResult ShareLink(string link..) //asp.net-mvc method as an example
{// maybe you could use dependency injection here to get ISocialService
ISocialService _service;
_service.ShareToTwitter(link);
}
这样您就可以清楚了解什么是业务逻辑:
MathService
{
int Add(a,b) { ..} //this is business logic
}
它需要做一些事情,并且无需触摸界面就可以完成,这需要封装。更多真实的例子是
SecurityService.ResetPassword()
从控制器调用时:
您可以使用在Web应用程序或Windows应用程序中添加的业务逻辑,并通过某个界面从用户那里获取输入。如何做到这一点就是控制器逻辑。
public ActionResult Calculate(int a, int b)//comes from webpage
{
//this is controller logic
int ret = MathService.Add(a,b);
//logic to send ret back
//to some other page to display to user.
}