服务层与辅助对象？

Question

我想听听您对具体案例的意见。这是关于服务层与辅助对象的——我不是在寻找理想主义的模式，而只是很好地理解我亲爱的编程同事对此的看法：

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

现在要注意了。我还有一些“助手”类，它们可以做加密之类的事情，而且我还在该目录中填充了其他不可分组的元素（例如自定义枚举等）

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

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

怎么办？你们把仍然是业务层级别的东西放在哪里，但同时如何限制业务/服务层中的项目数量？您将所有这些小助手类放在哪里，例如简化和管理 Session 访问的中间对象（我假设您希望拥有这种强类型 - 至少我愿意）？

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

Answer 1

对我来说，为工作使用正确的工具是关键。如果您需要某种工具来生成链接，这基本上是实体属性到格式化字符串的映射，那么请编写一个工具来执行此操作。它不一定是服务......相反，为类似的东西提供完整的服务可能是矫枉过正。但是，我不会将其归为您的一般“助手”。听起来这是有特定目的和意图的东西，背后有特定的行为。因此，将其放在适合该行为的位置......即使那是一个新项目。

我尽量不在我的应用程序中包含大量“通用”代码。一切都有一个目的并实现特定的行为。有时，这种目的和行为是高度可重用的，但我仍然尝试在逻辑上组织我的领域的那些可重用元素。从高层次来看，我看到我的大部分应用程序分为以下几类：

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

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