asp.net - 模块化软件设计

Question

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

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

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

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

Answer 1

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

I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.

听起来完全是矫枉过正。过度抽象会让你的应用程序在维护、支持和增强方面遇到困难。您需要将模块分成单独的解决方案吗？有那么大吗？

Is it the right approach of separating modules?

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

How the real world modular applications are developed?

使用抽象(接口(interface)和抽象类)和单独的项目。

How should the different modules communicate with each other yet they stay independent of each other.

通过使用接口(interface)、DI、IOC、TDD

I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?

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

There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)

我强烈建议使用 Core 项目的单个副本。请参阅this questions了解原因的详细信息。