Hi, One of the senior developers is proposing the following architecture for a big winforms application we are working on (the old VB6 version had 700 forms!!)

The application has 3 logical tiers, DAL (by LLBL), BL, and the WinUI

The proposal is to build each winform in its own project/dll. This means we will end up with almost 700 dlls for the project's forms.

The goal behind this architecture is to ease and speed development.

I would appreciate hearing any feedback for or against such a design?

I would start with trying to understand the claim that it would "ease and speed development". I actually can't imagine any justification for taking this approach.

One big downside--the solution file would be unmanageable. You could have a trimmed- down version of it for daily use, but then any changes to the BL would have to be checked against all UI projects to make sure everything still compiles.

It won't ease and speed development, it will make it more painful and slower. As well as the unmangeable solution file, there is also the build time to be considered - there is an overhead for each .dll that has to be built.

A much more sensible approach is to structure your UI projects into logical business groups - ie Customer forms, Product forms etc. Another approach is to use logical functional groups - list browsing forms, edit forms etc. Either of these is a much more manageable approach.

Matt

thanks for your feedback

The an other goal that he mention behind that architecture is to ease to do updates for customer by sending the modified dll . as updates could be either daily or weekly.

How is it any easier to send a customer 1 dll from 700, rather than 1 from dozen or so ?

And you shouldn't be updating customer systems in this manner anyway - build a proper installer and get them to update their installation. Otherwise it is way too easy to lose track of which version of your application they are using.

Matt