Home/ Questions/Q 993095
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T06:21:58+00:00

I am writing a Windows Forms application which is growing and becoming quite extensive.

  • 0

I am writing a Windows Forms application which is growing and becoming quite extensive.

Initially I thought that a separate project for graphical components and one for business logic and one for data access would be the best approach.

As the application gets larger I’m beginning to think that a more modular approach would be cleaner… e.g. a project containing user controls, business logic and data access for each ‘category’ of data.

For example… DAL objects relating to Products along with the associated business objects and user controls in a single project. This should end up with a larger number of projects within the solution, each one being self contained.

This may, however, cause more complications as the data is often linked (product table is linked with supplier table and orders table and parts list table etc.) So it would be difficult to completely abstract each category.

There are hundreds of software architecture articles online but not many which help you to translate that architecture into solutions, projects and code.

Could anyone point me in the right direction?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would keep UI, data and business layers in separate projects. This essentially reduces chance of tight coupling – for example, data layer being directly used by UI code etc. Now, if you wish to divide this vertically then you can do that as well as i.e. Products will have three projects UI, Business & Dal and so on. There can be multiple considerations out here:

    1. Why are you separating vertically – do you see a possible independent reuse? If no then avoid dividing.
    2. If you must divide then you may choose divide say only UI layer from management perspective because it may have lot of code
    3. Or you may divide all layers but at coarse grain. For example, Products and also its children together.

    As far as cross category references are concerned, they cannot be avoided but they must be done via well documented & designed contract. For example, Orders UI may call Products BL to get list of products (note that the same method will be used by many other UI components for similar functionality).

    • 0