首先,“最佳”解决方案是一个相当主观的术语。我通常会针对DRY、可重用、高性能的解决方案,促进最小的努力、摩擦和聊天,而其他人可能根据REST原则的贴近程度来定义“最佳”。因此,根据目标的不同,您将得到各种不同的回答。我只能提供我的方法。
ServiceStack服务实现与其自定义路由解耦
需要记住的一件事是,在ServiceStack中定义和设计服务在如何公开它们方面是相当解耦的,因为您可以在任何自定义路由下公开您的服务。ServiceStack鼓励基于消息的设计,因此您应该为每个操作分配一个独立的消息。
使用逻辑/分层URL结构
我会使用一个逻辑的URL结构,旨在表示名词的标识符,这个结构是有层次结构的,即父路径对资源进行分类并赋予其有意义的上下文。因此,在这种情况下,如果您想公开事件和评论,我的倾向是采用以下URL结构:
/events //all events
/events/1 //event
/events/1/reviews //event
每个资源标识符都可以使用任何HTTP动词。
实现:
对于实现,我通常遵循基于消息的设计,并根据响应类型和调用上下文分组所有相关操作。为此,我会做如下操作:
[Route("/events", "GET")]
[Route("/events/category/{Category}", "GET")]
public class SearchEvents : IReturn<SearchEventsResponse>
{
public string Category { get; set; }
public string Query { get; set; }
}
[Route("/events", "POST")]
public class CreateEvent : IReturn<Event>
{
public string Name { get; set; }
public DateTime StartDate { get; set; }
}
[Route("/events/{Id}", "GET")]
[Route("/events/code/{EventCode}", "GET")]
public class GetEvent : IReturn<Event>
{
public int Id { get; set; }
public string EventCode { get; set; }
}
[Route("/events/{Id}", "PUT")]
public class UpdateEvent : IReturn<Event>
{
public int Id { get; set; }
public string Name { get; set; }
public DateTime StartDate { get; set; }
}
并对事件回顾遵循类似的模式
[Route("/events/{EventId}/reviews", "GET")]
public class GetEventReviews : IReturn<GetEventReviewsResponse>
{
public int EventId { get; set; }
}
[Route("/events/{EventId}/reviews/{Id}", "GET")]
public class GetEventReview : IReturn<EventReview>
{
public int EventId { get; set; }
public int Id { get; set; }
}
[Route("/events/{EventId}/reviews", "POST")]
public class CreateEventReview : IReturn<EventReview>
{
public int EventId { get; set; }
public string Comments { get; set; }
}
根据这些信息,实现应该相当简单。我将在两个
EventsService和
EventReviewsService类中组织它们(取决于代码库的大小)。需要注意的是,我自己使用服务请求DTO名称的复数形式,以避免与同名的数据模型发生冲突。
虽然我在这里分离了
UpdateEvent
和
CreateEvent
,但如果用例允许,有时会将它们合并为单个幂等
StoreEvent
操作。
理想情况下,根级别的
AppHost项目应该保持轻量级和无实现。尽管对于只有几个服务的小型项目来说,一切都在一个项目中并在需要时简单地扩展架构是可以的。
对于中大型项目,我们建议采用以下物理结构,本示例我们假设我们的应用程序称为
EventMan。
项目的顺序也显示了它们之间的依赖关系,例如,最高级别的
EventMan
项目引用了
所有子项目,而最后一个
EventMan.ServiceModel
项目则没有引用任何其他项目。
- EventMan
AppHost.cs // ServiceStack ASP.NET Web or Console Host Project
- EventMan.ServiceInterface // Service implementations (akin to MVC Controllers)
EventsService.cs
EventsReviewsService.cs
- EventMan.Logic //For larger projs: pure C# logic, data models, etc
IGoogleCalendarGateway //E.g of a external dependency this project could use
- EventMan.ServiceModel //Service Request/Response DTOs and DTO types
Events.cs //SearchEvents, CreateEvent, GetEvent DTOs
EventReviews.cs //GetEventReviews, CreateEventReview
Types/
Event.cs //Event type
EventReview.cs //EventReview type
将EventMan.ServiceModel
DTO保留在其自己的独立实现和无依赖的dll中,您可以自由地在任何.NET客户端项目中原样共享此dll - 您可以使用任何通用的C#服务客户端与之配合,提供端到端的类型化API,而无需任何代码生成。
更新
IReturn<>
标记,我认为这仍是推荐的方法?你是否介意将它们添加到你的答案中,使其更加全面?这有助于澄清响应消息设计选择之间的[RequestName]Response
包装器消息与字面上的List<DTOType>
消息。 - Tyson