我们为不同的域/范围（特定于应用程序的数据，用户，管理等）提供多个WCF服务。我们将实体自动化到DTO，但在这里我遇到了第一个设计问题。
我们如何且应该将服务，合同和DTO分开？
如果我们需要对相同数据的不同观点，这是特别棘手的 - 即用户可能能够为自己读取数据，但不应获得任何相关的管理数据，因为这超出了他的范围。
我最初的做法是将所有DTO和合同放入每个域的单独程序集中，或者更确切地说是每个服务（例如CoreContracts，OrderContracts等）。然而，这使得对相同数据的不同观点的分离变得更加困难，特别是如果我不想仅仅为这些观点提供数据而添加新服务。
示例（省略属性）：
public class UserDto
{
public int UserId {get; set;}
public string Username {get; set;}
public string Email {get; set}
public string Address {get; set;}
public bool ExampleManagementFlag {get; set;}
}
这只是一个例子，实际上并不是如何实现的
ExampleManagementFlag是用户自己或代表用户的服务甚至不应该看到的东西。因此，我将使用单独的DTO进行用户端访问，再加上单独的合同，并将其放在相应合同程序集中的单独命名空间/文件夹中。
但是：使用单独的合同会使维护WCF绑定成为一场噩梦（多个服务，需要配置的多个环境 - 即每个开发人员都有一个调试环境，我们有一个测试部署环境和一个生产部署环境...） - 另一方面，将所有内容放在一个大型合同中会产生丑陋的方法，如GetUser(id)和GetUserForUser(id)等。
...我个人不喜欢的另一个选项（项目目前使用的......）将为每个客户端 - 服务器关系创建一个单独的合同。所以像OrderWebService.OrderWcfService，OrderWcfService.CoreWcfService，CoreWebService.CoreWcfService这样的东西 - 让我们不要忘记CoreWcfService.OrderWcfService ...
如果我们有单独的方法和DTO，授权就不是问题了。我希望避免为所有请求返回相同的DTO，因为这并不能告诉您哪些字段适用于哪个上下文 - 并且它会通过授权污染业务逻辑，而不是主要依赖基于资源的授权（即，Read上的用户可以UserScope.User，Read上的Superset.User - ReadForUser上的User，ReadAll但不是Alias "/myapp/css" "C:/Apache22/htdocs/myapp_static/css/"
<Directory "C:/Apache22/htdocs/myapp_static/css/">
Order allow,deny
Allow from all
</Directory>
。
我希望我所写的内容有意义或有助于解释我所面临的问题。我正在努力将这一点变成全面的话语。
编辑我们在该项目中使用的当前模式也导致了整个地方的字面复制DTO，其中可能需要分散某天的 < / p>