Question

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

是好的方法吗？或者“允许”演示者直接调用存储库吗？

Answer 1

有时候，当你不需要时，你不需要过度设计或强迫模式。

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.
}

Answer 2

我想说，如果您正在进行“严肃”的中等到大规模的开发，最好不要将业务逻辑放入您的表示层。如何隔离它是另一个问题。

另一方面，如果你使用像Entity Framework或NHibernate这样的东西，我只会创建存储库，如果真的有必要抽象数据访问，例如在测试时使用模拟。

服务层是否充当DAL的外观？

2 个答案: