业务逻辑应该走向何方？

Question

我正在开发一个Saas应用程序，它将使用ASP.NET MVC4和SQL Server。我计划有一个数据层(使用EF5)，一个服务层(可能只有RESTful服务)，一个DTO层，和Web层。稍后，我计划将此应用程序扩展到移动平台，适用于安卓和iPhone。也许是windows平板电脑。

通常，人们会为包含业务规则的域对象创建一个单独的层。然而，在我的例子中，如果我这样做了，那么我将不得不再次为android复制规则……对于iphone来说也是如此。因此，我在考虑将业务规则放在服务层本身中。然而，无论出于什么原因，这感觉都不太对劲。

对此有什么建议吗？

Answer 1

表示层必须保持原样。只是一个表示层。您的业务规则不应该在那里。我知道您的DTO将是为您的客户端(android、iphone、web等)提供的对象，因此不需要将您的业务对象传输到UI。将您的业务层隔离在服务器端，并让您的客户端使用它来获取他们需要显示的数据。

我的建议是使表示层与业务规则无关。使用这种方法将使您的解决方案具有可伸缩性，并且易于扩展。是应用关注点分离的好方法。

我是说..您可能会担心如何在不同的平台上共享DTO。我认为最好的方法是不向表示层提供.NET对象，因为您计划在表示层中使用不同的编程语言和技术。、JSON、和REST可以很好地解决您的问题。我建议使用Asp.net Web来处理json对象。Objective-c、Java和Javascript (适用于您的Web UI)可以处理此类对象。

Answer 2

你说过你有一个服务层。业务逻辑应该在它的背后。

Business layer -> (shared business objects) -> service layer -> (shared DTOs) -> presentation layers

其中表示层是MVC4、Android、IPhone等。它们都可以共享相同的DTO，但序列化方式不同。

Answer 3

从性能角度来看，复制每个平台的规则是可行的(因为它分离了不同设备之间的处理)，但是从维护、一致性等角度来看，您应该将业务规则放在服务层内/与服务层并行的工作流中。

http://msdn.microsoft.com/en-us/library/ee658103.aspx