我正在开发一个将使用 ASP.NET MVC 4 和 SQL Server 的 Saas 应用程序。我计划有一个数据层（使用 EF5）、一个服务层（可能只有 RESTful 服务）、一个 DTO 层和 Web UI 层。稍后，我计划将此应用程序扩展到移动平台，适用于 Android 和 iPhone ......也许是 windows 平板电脑。
通常，人们会为包含业务规则的域对象创建一个单独的层。但是，就我而言，如果我这样做了，那么我将不得不再次为 android 复制规则……再为 iphone 复制规则。所以，我在考虑在服务层本身内拥有业务规则。但是，无论出于何种原因，感觉都不对。
对此有何建议？
表示层必须是它是什么......只是一个表示层。您的业务规则不应该在那里。我了解您的 DTO 将是为您的客户提供服务的对象（android、iphone、web 等），因此无需将您的业务对象传输到 UI。将您的业务层隔离在服务器端，让您的客户使用它只是为了获取他们需要显示的数据。
我的建议是让表示层与业务规则无关。使用这种方法将使您的解决方案可扩展且易于扩展。是应用关注点分离的好方法。
这么说..您可能会担心如何在不同平台上共享您的 DTO。我认为最好的方法是不要使用 .NET 对象来提供表示层，因为您计划在表示层中使用不同的编程语言和技术。JSON和 REST 可以很好地解决您的问题。我建议使用 Asp.net Web Api 来处理 json 对象。Objective-c、Java 和 Javascript（用于您的 Web UI）可以使用这种对象。
你说你有一个服务层。业务逻辑应该在它后面。
Business layer -> (shared business objects) -> service layer -> (shared DTOs) -> presentation layers
表示层是 MVC4、Android、iPhone 等。它们都可以共享相同的 DTO，但序列化方式不同。
从性能的角度来看，为每个平台复制规则是可行的方法（因为它将不同设备之间的处理分开），但是从维护、一致性等角度来看，您应该将业务规则放在内部/并行的工作流中到服务层。