我正在阅读有关服务层和存储库的信息。现在,我想知道服务层是否必须包装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.
}

10-07 16:03
查看更多