模块化软件设计答案

【问题标题】：Modular Software Design模块化软件设计
【发布时间】：2013-04-25 08:11:17
【问题描述】：

我正在尝试在 asp.net 项目中实现模块化设计，将应用程序划分为不同的模块，如 HR、库存管理系统等。由于我试图保持不同的模块相互独立，因此我将这些模块分开每个模块都是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至是单独的数据库架构。

到目前为止，我认为这是开发管理系统和 ERP 的常见做法，但我在网上搜索了过去三天，但几乎没有找到任何有关开发模块化应用程序的完整内容。我发现的大部分只是解释内聚和耦合概念的理论，而不是现实世界的场景。所以我想知道

分离模块的方法是否正确？
现实世界的模块化应用程序是如何开发的？
不同的模块应该如何相互通信，同时又保持相互独立。
我认为应该有一个使用这些模块的核心应用程序，核心应用程序应该如何与这些模块通信？
每个模块都有一些数据，实体，对象，我应该将它们放在核心模块中以便其他模块使用它们（我认为这将使模块耦合到核心）还是应该每个模块维护自己的数据副本 + 定义这些对象，（我认为这会破坏 DRY）

热烈欢迎任何想法和链接。

【问题讨论】：

听起来您可能已经准备好使用基于消息传递的解决方案了。也许阅读《企业集成模式》一书并查看 NServiceBus。
这里的一个关键问题是，您的独立组件是否仅仅是单个 ASP.NET 应用程序中功能上的区别，还是具有自己的生命周期和部署计划的不同项目。这一切都将部署为一个网站吗？
@MattDavey 是的，它将被部署为单个网站。我想要实现的是假设如果客户想要带有模块 x 的核心应用程序，而另一个客户想要不带模块 x 的核心应用程序，作为服务提供商我应该是打开或关闭模块
啊，在那种情况下，这可能根本不是一个架构问题。在这种情况下，feature toggles 可用于向不同的客户端提供不同的功能。

标签： asp.net architecture module

【解决方案1】：

这是个人观点，值得商榷。

我将这些模块分开，使每个模块都是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至单独的数据库架构。

听起来完全是矫枉过正。抽象之上的抽象使您的应用程序难以维护、支持和增强。您需要将模块分成单独的解决方案吗？

分离模块的方法正确吗？

不，我认为这完全是过度设计。我建议使用项目来分隔模块。而不是单独的解决方案。解决方案的问题在于，它需要外部依赖管理工具，这需要大量的精力来引入和后期维护。

现实世界的模块化应用程序是如何开发的？

使用抽象（接口和抽象类）和单独的项目。

不同的模块应该如何相互通信而又保持相互独立。

通过使用接口、DI、IOC、TDD

我认为应该有一个使用这些模块的核心应用程序，核心应用程序应该如何与这些模块通信？

Core 不与模块通信。事实上，理想情况下它不应该依赖于任何其他项目/库。这使得在大型解决方案中引用和使用变得简单。

每个模块都有一些共同的数据，实体，对象，我应该将它们放在核心模块中以便其他模块使用它们（我认为这将使模块耦合到核心）还是应该每个模块维护自己的数据副本 + 定义那些对象，（我认为这会破坏 DRY）

我强烈建议使用来自 Core 项目的单个副本。有关原因的详细信息，请参阅this questions。

【讨论】：

+1 需要注意的是，其中很多点仅适用于中等规模的单一应用程序项目。我们无法确定 OP 的项目到底有多大。
非常感谢您提供如此详细的回复。假设如果我将模块划分为项目而不是解决方案，我应该如何组织 UI、BLL 和 DAL？我目前将 BLL 和 DAL 类库项目和 UI 实现为 asp.net 项目。
@ZedBee 是的，这正是我要做的
我应该如何为每个模块保留单独的 UI、BLL、DAL。
我认为这些是无效点。看不到任何性能问题，除非代码广泛使用单例与多线程结合。引入类的副本是一个地狱般的维护。单点故障在这里不适用，因为它更多地与网络中的节点有关。事实上，很高兴知道核心文件中的单行更改是否由于某种原因破坏了 BL 或 DAL 测试。您可以跟踪所有更改及其对整个系统的影响。

【解决方案2】：

这是大部分完全主观的主题之一，但您可能希望考虑 SOA（面向服务的架构）。

使用 SOA，您可以为每个业务领域（HR Web 服务、项目 Web 服务、财务网络服务等等。

然后，您可以将所有这些与将与这些服务进行通信并利用这些服务的前端系统结合在一起，这通常是您的核心应用程序，但根据您的需要和要求，您可以选择多个前端系统。

对于前端系统，我建议使用具有区域概念的 ASP.NET MVC，它可以让您将前端划分为特定区域 - 人力资源区域、项目区域、财务区域等等。包含每个特定区域的模型和视图。

这样做将使您以模块化方式构建，您可以构建您的第一个 Web 服务，例如 HR Web 服务，它具有获取相关 HR 数据等的方法，然后构建 MVC 的 HR 区域应用。然后扩展只依赖于构建 Web 服务，并在 MVC 应用程序中创建前端。如果 HR 区域需要财务信息，则无需访问财务 Web 服务，但它仍然将所有内容保存在不同的独立模块中。

使用此方法还有助于促进未来的互操作性 - 公司中的其他系统可能会发现与某些 Web 服务交互很有用。例如，在以前的角色中，公司工程软件与项目团队 Web 服务集成很有用，因为它允许将工程相关信息链接到其相关项目。

如果系统在资源需求方面增长，它也应该是相当可扩展的，因为如果它开始消耗大量系统资源，将项目 Web 服务卸载到另一个服务是微不足道的。它还允许您在需要时切换模块 - 如果您决定迁移到 Linux/Java 平台，您可以通过逐个模块移植来轻松迁移，而不会真正中断整个系统。

当然，正如我所说，这只是一种选择，很大程度上取决于您的具体情况。

【讨论】：

+1 我觉得这可能更接近 OP 的需求。然而，Web 服务并不是实现这一目标的唯一方法 - 消息队列解决方案通常更可取。
确实，为了 ZedBee 的利益，可能值得注意的是，在这种情况下，他可能希望查看 WCF 来提供他的服务，因为这为他提供了一种相当灵活的方式来使用不同的技术，如 MSMQ，如果这比 Web 服务更适合他的需求。

【解决方案3】：

现在回答为时已晚，但看起来很有趣。

由于我试图使不同的模块相互独立，因此我将这些模块分开，使每个模块都是一个单独的 Visual Studio 解决方案，具有 UI、BLL、DAL 甚至是单独的数据库架构。

这取决于您的应用规模。如果您创建了一个非常简单且功能很少的应用程序，那么使用组合程序集是安全的。或者，如果您愿意，只需将 UI 与其他模块分开即可。至少它可以帮助你强调SOC。请记住，加载多个程序集可能比单个程序集慢。

分离模块的方法正确吗？

模块分离总是有一个缺点，那就是需要映射。这通常意味着性能较慢（可能可以忽略不计，但仍然存在），以及较慢的开发时间。如果您的应用程序足够大且足够复杂，那么这是值得的，因为您可以为每个模块创建模块化单元测试。

现实世界的模块化应用程序是如何开发的？

虽然没有确切的实践，但每个问题都需要解决方案。一个简单的计算器应用程序不需要繁重的多线程或依赖注入架构。

不同的模块应该如何相互通信而又保持相互独立。

使用界面。您可以稍后使实现有所不同。例如，您当前为您的应用程序使用 C# Winform，使用接口与 BLL 通信。稍后，您想迁移到 ASP.Net，那么您只需更改实现，但保持与 BLL 通信的接口不变。

我认为应该有一个使用这些模块的核心应用程序，核心应用程序应该如何与这些模块通信？

每个模块都有一些共同的数据，实体，对象，我应该将它们放在核心模块中以便其他模块使用它们（我认为这将使模块耦合到核心）还是应该每个模块维护自己的数据副本 + 定义这些对象，（我认为这会破坏 DRY）

我假设它是一个企业级应用程序，它共享相同的模块/数据，例如员工。如果真的需要统一表现，那么您应该在核心级别提供非常基本的逻辑。在应用程序/实现级别，您可能有不同的实现来满足每个要求。

不要强制将所有业务逻辑统一到核心。如果特定应用程序需要不同的实现，则很难使核心可配置。

【讨论】：