我正在重新架构一个大型Web表单ASP.Net应用程序，插入服务层以从表示层中消除不必要的责任。
我见过很多例子，其中所有服务方法都包含在一个类中。
这是常见/最佳做法吗？或者在服务层中拥有多个服务类是否完全可行？我倾向于拥有多项服务，而且这些服务能够互相交流。
任何指导，优点/缺点？
理查德
P.S。请注意，我不是在谈论 web 服务层，WCF或其他，尽管这可能会在以后更加相关。
答案 0 :(得分：3)
SOLID principles，特别是Single Responsibility Principle会表明在一个对象中拥有所有功能是一个坏主意，我倾向于同意。随着应用程序的增长，单个类将难以维护。
您对Yuriys的回答会建议您使用IOC容器。让我们暂时考虑一下......
此单个类包含的功能越多，它所需的依赖性就越多。您最终可能会在服务上有一个具有很长参数列表的构造函数，因为该类涵盖了很多基础并依赖于较低级别的其他功能，例如日志记录，数据库通信，身份验证等。让我们说该服务的使用者想要在销毁该实例之前调用该服务，并且该类只有一个特定方法。您的IOC容器需要在运行时注入服务可能“可能”需要的每个依赖项，即使使用者只使用这些依赖项中的1个或2个。
同样从操作角度来看 - 如果团队中有多个开发人员同时处理服务层，如果您同时编辑一个文件，则更有可能发生合并冲突。但是，正如所建议的那样，你可以使用partials来解决这个问题。
通常，一种实用性和众所周知的模式或原则是最好的前进方式。
如果您还没有，我建议您研究Service Orientated Architecture，因为它可以帮助您回答解决方案中的一些关键决策。
答案 1 :(得分：2)
当然可以。 此外，我认为最好从这个上帝服务层类中提取一些功能（即ISecurityService，INotificationService等）接口，并在单独的项目中实现每个接口。此外，您可以利用一些IOC容器来解析实现服务接口的类。这样，您可以独立更改每个服务的实现，而无需更改客户端功能。
至少，您第一次将服务超类标记为部分，然后按功能将其拆分为几个具有有意义名称的.cs（.vb）文件，并在Visual Studio中将它们组合在一起。这将简化服务方法的导航。
答案 2 :(得分：0)
我对构建应用程序的看法是将应用程序拆分为两个项目AppX.Web（UI逻辑）和AppX.Business（业务逻辑），但仍然将它们保存在同一个VS解决方案中。业务逻辑和UI逻辑之间的结构阐明有助于您了解在多个网页之间共享哪些服务以及哪些服务是单个网页的本地服务。您应该避免在网页之间直接重复使用代码，如果您发现这是必要的，那么您应该将这段共享代码移动到业务逻辑层。
在实现业务逻辑项目时，您应该尝试为不同类型的业务逻辑创建单独的类。这些课程当然可以互相交谈，但不要让网页互相交谈。
一旦将UI逻辑与业务逻辑分离，您可以继续将AppX.Business代码分解为更小的部分（如有必要）。常见的例子包括：
最后，让我们谈谈全押并将您的业务逻辑公开为WCF服务。在这种情况下，您实际上不需要更改现有结构中的任何内容。您可以将WCF服务添加到现有的AppX.Web项目中，也可以在AppX.Service中单独公开它们。如果您将业务逻辑与UI逻辑正确分开，那么WCF层可以只是业务逻辑的一个薄包装。
在实现WCF服务时，很有可能在单个类中完成所有这些操作。 WCF服务中没有真正的业务逻辑，因为它只是直接调用业务逻辑。
如果你构建一个新的应用程序，你应该考虑你的整体设计，但现在你正在重新构建我认为你应该一步一步地工作：