我们正处于为公司设置内部企业API层的设计阶段。我们希望能够实现一个可以为我们的内部应用程序以及外部客户端提供服务的API。我们的环境是MS重，IIS，ASP.NET MVC应用程序等。
我们有一个设计不好的现有服务层，所以我们这次尝试正确。
This question表示主要文档中不再存在的较大ServiceStack项目的项目细分。主要是包含一个独立的逻辑＆＃34;项目。我们正在尝试将此与Martin Fowler在企业应用程序架构模式中概述的很多内容保持一致。
以下是我们正在考虑的事项：
○ Service.Host (single)
§ Dumb Host
§ Assigned multiple Service Interfaces on startup (subsystems)
○ Service.Interfaces (many projects)
§ Subsystems of Business (e.g. Ordering, Customers, etc)
§ Data Access Layer with Repository pattern
§ Service Layer endpoints
□ Application endpoints (returns data/dtos for views/screens)
□ Vendor Endpoints (Feeds, hierarchies, etc; authentication/authorization)
○ Service.Models (single)
§ DTOs for all systems (namespaced appropriately?)
§ Shared and distributed to vendors/client apps
§ No dependencies
○ Service.Logic
§ Rich Domain Layer
□ Objects that model our business
□ Rules/algorithms for business logic
○ Service.Tests
Fowler和其他人建议DTO和Business Logic应该相互独立，使用Assembly / Factory类进行转换。
第一个问题：装配工在哪里生活？在服务接口项目中？在他们自己的项目？每次转换都需要它们吗？
其次：客户端是否需要转换回域对象，或者客户端是否只使用DTO来填充屏幕并将数据发送回服务？我们只希望客户端依赖于Service Models类，对吧？
第三：我们如何设计DTO？以前，它们是代表一种资源的pocos（试图保持安静，OrderDTO，CustomerDTO等）。实际上，所需的数据很复杂。我们最初认为客户可以单独请求他们需要的任何内容并将其重新组合在一Fowler表示我们希望最小化对服务的请求，并且具有几乎是业务对象聚合的dtos，以尝试立即将其全部发送出去。因此，如果我有一个订单并希望客户与之相关联，那么我是否应该发送一个包含所有内容的CustomerOrderDTO？或者我是否发送订单对象，并强制客户再次发出订单请求？
第四：使用实际的C＃接口在哪里？我们是否为每个存储库都有一个可以切换和测试它们？每个服务接口一个？
第五：除了在每一层映射之外别无选择吗？即使用ORM的SQL到数据层。使用AutoMapper或ServiceStack映射器将数据层转换为域层。域层到DTO。 DTO到ViewModel。 ViewModel到Javascript模型（例如Knockout）看起来好像很多重复和样板。还有更好的方法吗？
我试图不使这个主观 - 但这里的一些细节很少有指导 - 我们的假设是我们在ServiceStack框架中缺少最佳实践或意图来解释这些事情。提前感谢您回答上述任何问题。
答案 0 :(得分：3)
这包含太多广泛的问题，无法深入回答，问题不应该有多个脱节问题涉及不同的主题，你应该把它分成多个有针对性的问题，这样才能清楚问题是什么，答案是什么？期待。
我首先建议浏览ServiceStack文档中的Designing APIs部分，该部分介绍如何使用ServiceStack设计API。
要特别注意Software complexity, goals of Services and important role of DTOs，因为它涵盖了创建服务时应该考虑的许多内容。例如。如果您使用code-first POCO Micro ORM like OrmLite，则可以在DTO，ViewModel，缓存提供程序等中重复使用数据模型。但是当您需要时，可以使用ServiceStack的built-in AutoMapping轻松地在模型之间进行映射＆lt; - ＆GT; DTO的。无论哪种方式都试图避免在每层中有多个人造层和不同模型，这是不必要摩擦的一个重要来源。
它还强调，您应该尽可能减少任何不必要的图层/图案/等，因为每次添加图层时都会添加人工摩擦，因此请确保添加的每个图层都有用，您可以看到他们各自增加的价值。例如。我建议不要使用多个细粒度的存储库，我通常会有一个存储库来覆盖相关功能的整个子系统，并强烈建议不要根据与您无关的任意规则机械创建细粒度存储库领域，例如每表。
如果您有多个实现或者想要编写模拟它们的测试，那么您只需要C＃接口。
ServiceStack鼓励coarse-grained Message-based Services代替客户端特定的细粒度RPC服务，尝试设计通用的，可重用的，批量服务，最大限度地减少强制客户端执行多个依赖I / O服务并发送客户端所需的数据单个服务响应，当它与该请求紧密相关时。
ServiceStack的Physical Project Structure已在大多数ServiceStackVS VS.NET Templates中实现，因此我建议使用最合适的ServiceStackVS模板启动新项目。例如。 {Project} .ServiceInterface 包含服务实现，而 {Project} .ServiceModel 将DTO保存在一个无impl的项目中，因此可以重用这些类型。
只需在单独的 ServiceModel 项目中维护DTO，就可以消除客户的摩擦，这些客户可以将任何类型的DTO与任何ServiceStack C#/.NET Client重用，以启用端到端的Typed API而无需努力。
客户还可以使用ServiceStack的Add ServiceStack Reference功能导入远程服务的所有类型，而不是共享 ServiceModel 项目，它可以与C＃客户端一起使用以启用类型化API。要了解这是如何以及为什么实时结帐Add ServiceStack Reference on Gistlyn，它允许您从浏览器调用任何远程ServiceStack服务。