企业应用程序中的表示层架构
在我们公司，我们正在开发一个由多个模块组成的应用程序。该架构已经基本定义，但我对表示层有一些想法，我真的很想听听您的意见。架构如下：
对于每个模块，我们创建几个命名空间，这些命名空间将被编译到它们自己的类库中。因此，对于我们的 CRM 模块，我们创建以下内容：
- ProductName.CRM.ServiceLayer（保存 CRM 模块的服务合同接口）
- ProductName.CRM.ServiceLayer.Implementation（实现 CRM 模块的服务层接口）
- ProductName.CRM.BusinessLayer（保存 CRM 模块的业务组件） CRM模块）
- ProductName.CRM.BusinessLayer.BusinessObjects（保存CRM模块的businessObjects）
- ProductName.CRM.DataLayer（保存CRM模块的DAO接口）
- ProductName.CRM.DataLayer.SqlServer（实现CRM模块的数据层接口）
我们创建Finance、HRM、Supply 等模块的类库结构相同：
- ProductName.Finance....
- ProductName.HRM....
- 等。 我想你现在就明白了:)
我们还考虑了“横切问题”，为此我们创建了以下命名空间和类库
- ProductName.Framework.ExceptionHandling
- ProductName.Framework.Logging
- ProductName.Framework.Security
- 等等...
这就是我们到目前为止的架构，目前我正在尝试找到一种正确的方法来设置PresentationLayer。例如，我应该为每个模块创建一个PresentationLayer库（ProductName.CRM.PresentationLayer、ProductName.Finance.PresentationLayer等）。并创建一个整体 ProductName.PresentationLayer 库，该库引用所有其他 Module.PresentationLayer 库。然后，整个 ProductName.PresentationLayer 将具有登录/MainForm 功能以及启动在PresentationLayer 模块之一中实现的表单的能力。它就像应用程序到其他模块的入口点。
或者...
我应该只制作一个包含所有模块的所有表单的 ProductName.Presentation-library 吗？通过这样做，我可以轻松导航到其他表单，并且当模块要使用彼此的表单时不必担心模块之间的引用（有时他们会这样做）。
第一个解决方案对我来说听起来不错。然而，当来自不同模块的表单想要相互导航时。这种功能将很难实现，因为两者中只有一个可以引用另一个。
我真的很想听听您对我正在处理的这个问题的意见，也许有人可以给我一个合适的解决方案或我可以使用的想法。
提前致谢， 干杯!
At our company we are developing an application that will consists of several modules. The architecture is pretty much defined but I have seconds thoughts about the presentationlayer and I would really like to hear your opinions. The architecture is as follows:
Foreach module we create several namespaces and those will be compiled in their own class library. So for our CRM module we create the following:
- ProductName.CRM.ServiceLayer (holds the servicecontracts interfaces of CRM module)
- ProductName.CRM.ServiceLayer.Implementation (implements the servicelayer interfaces of CRM module)
- ProductName.CRM.BusinessLayer (holds the businesscomponents of CRM module)
- ProductName.CRM.BusinessLayer.BusinessObjects (holds the businessObjects of CRM module)
- ProductName.CRM.DataLayer (holds the DAO interfaces of CRM module)
- ProductName.CRM.DataLayer.SqlServer (implements the datalayer interfaces of CRM module)
We create the same structure of class libraries for the modules Finance, HRM, Supply, etc:
- ProductName.Finance....
- ProductName.HRM....
- etc.
I think you will get the idea for now :)
Also we thought about the "Crosscutting Concerns" and for that we create the following namespaces and class libraries
- ProductName.Framework.ExceptionHandling
- ProductName.Framework.Logging
- ProductName.Framework.Security
- etcetra...
So that is how our architecture is so far and at this moment I'm trying to find a proper way for setting up the PresentationLayer. For example, should I make a PresentationLayer-library foreach module (ProductName.CRM.PresentationLayer, ProductName.Finance.PresentationLayer, etc.). And make an overall ProductName.PresentationLayer-library who has references to all the other Module.PresentationLayer-libraries. This overall ProductName.PresentationLayer will then have the Login/MainForm functionality and the ability to start forms that are implemented in one of the modules PresentationLayer. It will be like an entry point of the application to other modules.
Or...
Should I make just one ProductName.Presentation-library that contains all forms for all modules. By doing that that I can easly navigate to other forms and don't have to worry about references between modules when they are going to use each others forms (sometimes they will do).
The first solutions sounds good to me. However, when forms from different modules wants to navigate to each other.This kind of functionality will be tough to implement because only one of the two can have the reference to the other.
I would really like to hear your opinions about this issue I'm dealing with and maybe someone could give me a proper solution or idea that I can use.
thanks in advance,
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果表单需要交换数据，您始终可以创建表单实现的接口。事实上，让大量表单相互了解可能不是一个好主意，因为从长远来看，这会产生维护和增强问题跑步。
通过使用接口和潜在的某种定位器服务，您可以避免表单之间的硬连线依赖性 - 然后您可以自由使用任一架构模型（1 个大型程序集与许多较小的程序集）。
You can always create interfaces that forms implement if they need to exchange data. In fact, it's probably not a great idea to have lots of forms knowing about each other as that creates maintenance and enhancement problems in the long run.
By using interfaces and potentially some kind of Locator service, you can avoid hardwiring dependencies between forms - and then you are free to use either architectural model (1 big assembly vs. many smaller ones).