什么是适合大规模ServiceStack/的项目架构?网络项目

本文关键字：项目 网络 大规模 ServiceStack 什么 | 更新日期: 2023-09-27 18:02:53

我们正处于为公司建立内部企业API层的设计阶段。我们希望实现一个API，可以服务于我们的内部应用程序以及我们的外部客户端。我们的环境是重MS, IIS, ASP。. NET MVC应用程序等

我们现有的服务层设计得不太好，所以我们这次要努力把它做好。

这个问题表明了大型ServiceStack项目的项目分解，这些项目不再出现在主文档中。主要是包含一个单独的"Logic"项目。我们正试图将其与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和业务逻辑应该相互独立，使用汇编/工厂类在两者之间进行转换。

第一个问题:组装者住在哪里?在服务接口项目中?在他们自己的项目中?它们对于每次转换都是必需的吗?

第二:客户端是否需要转换回域对象，或者客户端是否只使用dto填充屏幕并将数据发送回服务?我们只希望客户端依赖于Service Models类，对吗?

第三:我们如何设计dto ?以前，它们是代表一个资源的poco(尝试restful、OrderDTO、CustomerDTO等)。实际上，所需的数据是复杂的。我们最初认为客户单独要求他们需要的东西，然后把它们拼凑在一起。Fowler指出，我们希望最小化对服务的请求，并拥有几乎是业务对象聚合的dto，以便尝试一次将所有请求都发送下来。因此，如果我有一个订单，并且希望将客户绑定到它，我是否应该发送一个CustomerOrderDTO，并填充所有内容?或者我发送一个订单对象，并强制客户端为该订单发出另一个请求?

第四:在什么地方使用实际的c#接口是合适的?我们是否为每个存储库都提供了一个可切换和可测试的存储库?每个服务接口一个?

第五:除了在每一层都映射之外，没有别的选择吗?即使用ORM的SQL到数据层。使用AutoMapper或ServiceStack映射器从数据层到域层。域层到DTO。DTO到ViewModel。从ViewModel到Javascript模型(例如Knockout)，看起来有很多重复和样板文件。有没有更好的办法?

我尽量不让这显得主观——但是这里的一些细节几乎没有指导方针——我们的假设是存在一些我们在ServiceStack框架中缺少的最佳实践或意图来解释这些事情。

什么是适合大规模ServiceStack/的项目架构?网络项目

这包含了太多宽泛的问题，无法深入回答，问题不应该有多个涉及不同主题的脱节问题，你应该把它分成多个重点问题，这样就能清楚地知道问题是什么，以及它期望的答案是什么。

我首先推荐阅读ServiceStack文档中的设计api部分，该部分介绍了如何使用ServiceStack设计api。

特别注意软件的复杂性、服务的目标和dto的重要作用，因为它涵盖了创建服务时应该考虑的许多内容。例如，如果你使用像OrmLite这样的代码优先的POCO Micro ORM，你可以在你的dto, ViewModels, Caching Providers等中重用数据模型。但是当你需要的时候，你可以使用ServiceStack内置的AutoMapping来轻松地在模型之间进行映射。无论哪种方法，都要尽量避免使用多个人工层和每层中不同的模型，这是不必要摩擦的主要来源。

它还强调，你应该尽可能减少任何不必要的层/模式等，因为每次你添加一个层，你都在增加人为的摩擦，所以要确保你添加的每个层都有一个目的，你可以看到它们每个增加的价值。我通常会有一个存储库来覆盖相关功能的整个子系统，并且强烈建议不要基于一些与您的领域无关的任意规则机械地创建细粒度存储库，例如每个表。

只有当你有多个实现或者想要编写模拟它们的测试时，你才需要c#接口。

ServiceStack鼓励粗粒度的基于消息的服务，而不是客户端特定的细粒度RPC服务，尝试设计通用的、可重用的、批处理的服务，以最大限度地减少强制客户端执行多个依赖的I/O服务，并在与请求内聚时在单个服务响应中发送客户端需要的数据。

ServiceStack的物理项目结构已经在大多数ServiceStackVS VS.NET模板中实现了，所以我建议使用最合适的ServiceStackVS模板开始一个新项目。例如}{项目。ServiceInterface保存服务实现，而{Project}。ServiceModel保存无impl项目中的DTO，以便可以重用这些类型。

通过在单独的ServiceModel项目中维护dto，它消除了客户端可以在任何ServiceStack c#/中重用类型化dto的摩擦。NET客户端可以毫不费力地启用端到端类型化API。

除了共享你的ServiceModel项目，客户端还可以使用ServiceStack的Add ServiceStack Reference特性来导入远程服务的所有类型，它可以与c#客户端一起使用以启用类型化API。要了解其工作原理和原理，请在Gistlyn上添加ServiceStack引用，该引用允许您从浏览器调用任何远程ServiceStack服务。
相关文章：