Large project strategy

JonM posted on Saturday, January 27, 2007

Hey Guys,

I'm just finishing up my largest project to-date. 150 business objects, 70 datbase tables, 360+ stored procedures, VB.net 2.0 Winforms App deployed with clickonce using the CSLA 1.5x, over 150,000 lines of code in the business objects + winforms client code. This project is huge (at least to me) and while I'm glad it is nearly over I can't help thinking about how I would do things different in version 2. (Odds are that's a couple of years away). One of the biggest changes I'm thinking about is breaking the entire system into modules (this program is business+accounting+inventory+workorder system by the way). I'm thinking if I were to build a general set of infrastructure up first with module support that I could then build and test a module one at a time. I'm also thinking that I could write custom versions for specific customers by just writing new modules or replacing existing modules with custom versions. Anyway, in my mind a module should contain the following:

1 assembly that contains all of the business objects
1 assembly that contains all of the winforms forms and admin dialogs
1 assembly that contains all of the webforms forms and admin dialogs
MetaData that describes security information and permissions options for this module
MetaData that describes dependencies on other modules and versions
MetaData that contains module specific features that can be enabled or disabled depending on your needs
All of the reporting services report definitions (.rdl) that are associated with this module
All of the unit tests for this module
The .SQL files that make up the tables, functions, and stored procedures that the business objects in this module use.
Some sort of test component that can verify the database schema and some sort of basic data-integrity (sanity check) for the data for these modules that runs when the winforms client loads.

Okay, so here is my question, does this make sense?? Is there a better way? What does everyone else to on bigger projects? The only downside I see is that this will create a 3 assemblies for each module and that I'll have to keep track of all them and make copies of them to my dataportal.

Jon

William replied on Saturday, January 27, 2007

I would choose to separate the system into modules by functional areas, accounting, inventory, workorder, etc. Each module can be implemented as a set of DLLs, which consists Win/Web UI, Business Objects, Services, etc. Then, the hosting application (WinForms EXE, or ASP.NET) integrates these DLL modules to form the entire system. Also, each module has its own databases, which can be integrated through distributed transactions.

Regards,
William

JonM replied on Monday, January 29, 2007

William,

I think we see eye to eye on just about everything. I'm not sure about breaking modules into seperate databases. Do you see any advantages to breaking the databases apart?

William replied on Monday, January 29, 2007

I am just thinking in general sense. In many cases, I found these systems (or modules, e.g. inventory, order, accounting, etc.) have separate databases and thus my suggestions.

Besides, if separating the databases do not create much performance issues for your application, it might help you to better organizes the large number of database objects (e.g. tables, views, stored procedures, etc.) you may have for the whole project.

Regards,

William

William replied on Monday, January 29, 2007

Did you look at Microsoft Composite UI Application Block (CAB)? I would recommend you to have a look.

Although personally I think CAB is a steep learning curve, I think it can give you some insights in modularizing your application (even you are not adopting it).

Regards,

William

JonM replied on Monday, January 29, 2007

I've heard of it, but never lookit at it. I will research it, thanks.

DesNolan replied on Tuesday, January 30, 2007

No need to break into separate modules at this time, but if you're working with SQL 2005, consider separate 'schemas' that is what I did with mine. That way a person working on a particular domain area can find all the tables, store procedures, etc, all grouped together.

Cheer,

Des Nolan