服务层与助手对象？

Question

我想就某个具体案例发表您的意见。这是关于服务层与辅助对象 - 而且我不是在寻找理想化的模式，而只是很好地理解我亲爱的编程同事对此的看法：

在我当前的应用程序中，我有一个完整的域模型Linq to Sql，非常轻量级的存储库，然后使用IQueryable的扩展方法<>根据业务需求过滤/排序/排序），然后包含基于责任分组的服务的服务层，例如IRegistrationService（注册用户，登录名的可用性等）

现在的警告。我也有一些类似加密的“助手”类，并且我还在该目录中填充了其他不可用的元素（例如自定义枚举等）。

我需要创建一个新的类，它将处理为我的应用程序生成自定义链接，这比仅使用不同对象并考虑其属性的String.Format更多。内部工作是无关紧要的。然而，我现在很难实例化某种类型的“LinkService”，因为我会完成这些工作 - 当我完成后，我觉得最终会有100个服务（及其接口+实现）。

同时我不想在我的“Helpers”命名空间/目录（例如LinkManager）中创建一些类和其他东西的松散混合。

怎么办？你们在哪些地方放置了仍然有点商业层次的东西，但同时又如何限制商业/服务层中的商品数量？你在哪里坚持所有这些小助手类，如简化和管理会话访问的中间对象（我假设你想要这种强类型 - 至少我是这样做的）？

让我知道您的想法？谢谢 ！

Answer 1

对我来说，使用正确的工具来完成工作是关键。如果您需要某种设施来生成链接，这基本上是实体属性到格式化字符串的映射，然后编写一个工具来执行此操作。它不一定是一种服务......相反，为这样的事情提供全面的服务可能是矫枉过正的。但是，我不会把这一点变成你的一般“助手”。这听起来像是有某种特定目的和意图的东西，背后有一种特定的行为。因此，把它放在适合这种行为的地方......即使这是一个新项目。

我尽量不要在我的应用程序中使用大量的“通用”代码。一切都有目的并实现特定的行为。有时候这种目的和行为是高度可重用的，但我仍然尝试从逻辑上组织那些可重用的元素。从一个高的水平，我看到我的大多数应用程序分为以下几种：

1. 客户
2. API /服务
3. 域
4. 数据访问（可选）
5. 框架

许多这种可重用的功能都属于框架和域之间的一个下级区域。它的一部分可能作为框架中的一些基类和/或接口和支持类型存在，而另一半，具体实现则存在于我的域中。它有时看起来很奇怪，但以这种方式组织起来可以帮助我尽可能地保持域名清晰（专注于业务问题），同时仍然允许我将通用和可重用概念抽象为较低级别的“框架”类型。