1

我们正在规划我们的架构并考虑如何将我们的类分组到 WCF 服务中。

我们可以为每个类或紧密的类集合创建一个服务。例如,一项服务用于处理与用户数据有关的所有事情。这将导致相当多的相对较小的服务。

或者,我们可以将类分组创建为服务。例如,一项服务包含所有数据实体(用户、订单、客户等)的类。

或者介于两者之间。

我可能对这些应该如何相关或在错误的地方查找有误解,但我找不到任何指导。

拥有许多服务是个坏主意吗?他们每个人都有很大的开销吗?如果我们确实对它们进行了分组,然后想更改分组,那会是一个问题吗?

4

2 回答 2

3

我将确定我的逻辑的哪些部分需要对服务的消费者可用。

它会是一组类似 CRUD 的服务,大量的添加、更新、删除吗?WebAPI 可能是 WCF 的一个很好的轻量级替代方案。额外的好处是,如果您认为该用例是有价值的,那么您可以让更广泛的消费者(不仅仅是 .NET)开箱即用地访问这些服务。

我会看看你如何看待你的消费者使用你的服务。我认为拥有一个单一的服务与许多较小的服务相比没有任何额外的开销成本。从应用程序池的角度来看,拥有多个较小的服务甚至可能是有利的。

老实说,我认为组织服务的方式没有错误。你正在考虑它的事实足以让我相信你不会把事情搞砸。

于 2013-09-12T21:50:58.373 回答
1

如果您正在考虑向客户端提供数据,您可能希望仅将 OData 用于纯粹的数据传输,然后在您的 OData 服务上使用服务方法来满足任何特殊处理需求。那将是我的建议。我见过一些真正糟糕的 WCF 实现,因为它们使用 WCF 进行数据传输和处理。OData 拥有大量不同编程语言的客户端库。通过使用 OData 和拦截器,您可以节省大量的编码时间。

编辑:

我应该提到 OData 不一定是灵丹妙药,事实上,一些用例会更多地用于具有 AutoMapper(nuget 包)实现的 DTO(数据传输对象),但我是 OData 的忠实粉丝。

附加编辑:

我知道 DTO 和 AutoMapper 在代码中有点冗长,但我一直从 Xamarin Mobile 的角度思考,这些 DTO 类直接推送到您的移动项目中,使用您的服务进行映射变得轻松快捷,而且您会得到很多的代码重用。特别是如果您需要在 SQLLite 中的移动设备上进行本地数据缓存。

于 2013-09-12T20:17:22.053 回答