商业逻辑应该去哪里？

我正在使用将使用ASP.NET MVC 4 & SQL Server的Saas应用程序。我打算有一个数据层（使用EF5），一个服务层（可能只有RESTful服务），一个DTO层和Web UI层。后来，我打算将此应用程序扩展到移动平台，对于Android & iPhone ...也许是Windows平板电脑。商业逻辑应该去哪里？

通常，可以为包含业务规则的域对象创建单独的图层。然而，在我的情况下，如果我这样做，那么我将不得不复制规则再次为Android ...并再次为iPhone。所以，我正在考虑在服务层本身中拥有业务规则。然而，无论出于何种原因，这都不合适。

对此有何建议？

来源

2012-09-21 Skadoosh

你为什么要复制android的规则？业务规则在域中，除非你谈论“表示逻辑”。您应该有一个包含业务对象和相关业务逻辑的域图层。然后其他层引用此。 – RPM1984

最初的所有内容都将以.net编写。如果我在单独的业务层中编写规则，是否可以在Android或iPhone OS中使用相同的dll？ – Skadoosh

你能举出一个你会在不同应用程序中执行的“业务规则”的例子吗？ – RPM1984

表示层必须是它是什么..只是表示层。你的商业规则不应该在那里。我明白你的DTO将会是你的客户端（android，iphone，web等等）的对象，所以不需要将你的业务对象转移到UI。将您的业务层隔离在服务器端，让您的客户使用它来获取他们需要显示的数据。

我的建议是使表示层不知道业务规则。使用这种方法将使您的解决方案可扩展并易于扩展。是一种适用问题分离的好方法。

说出来..你可能会担心如何在不同的平台上分享你的DTO。我认为最好的方法是不要用.NET对象提供表示层，因为您打算在表示层使用不同的编程语言和技术。 JSON和REST可以很好地解决您的问题。我建议使用Asp.net Web Api来处理json对象。 Objective-c，Java和Javascript（用于Web UI）可以使用这种对象。

来源

2012-09-21 07:19:58 margabit

你说，你有一个服务层。业务逻辑应该落后于它。

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

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

来源

2012-09-21 10:11:33 jgauffin

从性能角度看，复制的规则为每个平台是去（因为它分离不同的设备之间的处理），但是从维护性，一致性等角度来看，你应该把业务规则在工作流的方式，在服务层内/并行。

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

来源

2013-11-22 18:25:37 Dave

商业逻辑应该去哪里？

回答

相关问题