我们为不同的域/范围（特定于应用程序的数据，用户，管理等）提供多个WCF服务 . 我们将实体自动化到DTO，但在这里我遇到了第一个设计问题 .
我们如何能够并且应该将服务， Contract 和DTO分开？
如果我们需要对相同数据的不同视图，这是特别棘手的 - 即用户可能能够为自己读取数据，但不应获得任何相关的管理数据，因为这超出了他的范围 .
我最初的做法是将所有DTO和 Contract 放入每个域的单独程序集中，或者更确切地说是每个服务（例如 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进行用户端访问，再加上单独的 Contract ，并将其放在相应 Contract 程序集中的单独命名空间/文件夹中 .
But: 使用单独的 Contract 会使维护WCF绑定成为一场噩梦（多个服务，需要配置多个环境 - 即每个开发人员都有一个调试环境，我们有一个测试部署环境和一个 生产环境 部署环境......） - 另一方面，将所有东西都放在一个大 Contract 中会产生丑陋的方法，如 GetUser(id) 和 GetUserForUser(id) 等 .
...我个人不喜欢的另一个选项（项目目前使用的......）是为每个客户 - 服务器关系创建一个单独的 Contract . 像 OrderWebService.OrderWcfService ， OrderWcfService.CoreWcfService ， CoreWebService.CoreWcfService 这样的东西 - 让我们不要忘记 CoreWcfService.OrderWcfService ......
如果我们有单独的方法和DTO，授权不是一个问题 . 我告诉你哪些字段适用于哪个上下文 - 它会用授权污染业务逻辑，而不是主要依赖基于资源的授权（即用户可以在 UserScope.User 上 Read ，但 Superset.User 上不 Read - 或 User 但不是 ReadForUser ReadAll ） .
我希望我所写的内容有意义或有助于解释我所面临的问题 . 我正在努力把它变成全面的话 .
编辑我们在该项目中使用的当前模式也导致在整个地方实际上复制了DTO，并认为它可能需要在某一天发散