views:

110

answers:

1

Hi everyone,

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!

+1  A: 

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).

LBushkin
What do you think about that overall presentationlayer library that acts like an entry point of the application and modules?Ik think that library wil also contain the login functionality and the ability to enable modules for specific userroles.The modules that are enabled for a specific userrole are defined in the business logic of course.
Lionel