企业应用程序中的表示层体系结构

Question

在我们公司，我们正在开发一个由几个模块组成的应用程序。这个架构已经定义了很多，但我对表示层有几点想法，我真的很想听听你的意见。架构如下：

Foreach模块我们创建了几个名称空间，这些名称空间将在他们自己的类库中编译。因此，对于我们的CRM模块，我们创建以下内容：

• ProductName.CRM.ServiceLayer（保存服务包含CRM模块的接口）
• ProductName.CRM.ServiceLayer.Implementation（实现CRM模块的服务层接口）
• ProductName.CRM.BusinessLayer（保存CRM模块的业务组件）
• ProductName.CRM.BusinessLayer.BusinessObjects（保存CRM模块的businessObjects）
• ProductName.CRM.DataLayer（保存CRM模块的DAO接口）
• ProductName.CRM.DataLayer.SqlServer（实现CRM模块的数据层接口）

我们为模块Finance，HRM，Supply等创建相同的类库结构：

• ProductName.Finance ....
• ProductName.HRM ....
• 等。 我想你现在会得到这个想法：）

我们也考虑过“Crosscutting Concerns”，为此我们创建了以下命名空间和类库

• ProductName.Framework.ExceptionHandling
• ProductName.Framework.Logging
• ProductName.Framework.Security
• etcetra ...

这就是我们的架构到目前为止的方式，此时我正试图找到一种正确的方法来设置PresentationLayer。例如，我应该创建PresentationLayer-library foreach模块（ProductName.CRM.PresentationLayer，ProductName.Finance.PresentationLayer等）。并创建一个包含所有其他Module.PresentationLayer-libraries的整体ProductName.PresentationLayer-library。这个整体ProductName.PresentationLayer将具有Login / MainForm功能，并能够启动在其中一个模块PresentationLayer中实现的表单。它将像应用程序的入口点到其他模块。

或者...

我应该只创建一个包含所有模块的所有表单的ProductName.Presentation库。通过这样做，我可以轻松地导航到其他表单，并且不必担心模块之间的引用，当他们将使用彼此的表单时（有时他们会这样做）。

第一个解决方案对我来说听起来不错。但是，当来自不同模块的表单想要相互导航时。这种功能很难实现，因为只有两个中的一个可以引用另一个。

我真的很想听听你对我正在处理的这个问题的看法，也许有人可以给我一个适当的解决方案或想法，我可以使用。

提前谢谢， 干杯！

Answer 1

如果需要交换数据，您总是可以创建构成工具的接口。事实上，让很多表单了解彼此可能并不是一个好主意，因为这会产生维护和增强问题长期来说。

通过使用接口和可能的某种Locator服务，您可以避免表单之间的硬连线依赖关系 - 然后您可以自由使用任何架构模型（1个大型组件与许多较小的组件）。