我们正在规划我们的架构并考虑如何将我们的类分组到 WCF 服务中。
我们可以为每个类或紧密的类集合创建一个服务。例如,一项服务用于与用户数据有关的所有事情。这将导致大量相对较小的服务。
或者,我们可以将类分组创建到服务中。例如,一项服务包含所有数据实体(用户、订单、客户等)的类。
或介于两者之间。
我可能对这些应该如何关联或在错误的地方寻找有误解,但我找不到任何指导。
有很多服务是个坏主意吗?他们每个人都有很大的开销吗?如果我们确实对它们进行了分组,然后又想更改分组,这会成为一个问题吗?
我会确定我的逻辑的哪些部分需要对服务的消费者可用。
它会是一组类似 CRUD 的服务,大量的添加、更新、删除吗? WebAPI 可能是 WCF 的一个很好的轻量级替代品。额外的好处是,如果您认为该用例是有值(value)的东西,您可以开箱即用地让更广泛的消费者(而不仅仅是 .NET)访问这些服务。
我会看看您如何看待您的消费者使用您的服务。我没有看到拥有一个单一的服务与许多较小的服务相比有任何额外的间接费用。从应用程序池的角度来看,拥有多个较小的服务甚至可能是有利的。
老实说,我认为组织服务的方式没有错。你正在考虑它这一事实足以让我相信你不会把它搞砸。