Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Why use multiple projects for solution??

Status
Not open for further replies.

golcarlad

Programmer
Nov 23, 2004
232
GB
Ok - so here is another type of "Best Practice" type question about orgainising code - but I have often wondered what are the main benefits of having lots of projects compiling under one solution - I understand it helps to encourage reuseability, ie. you can include refs to dlls in different projects and resuse the goodness that lies within - but how do you know when you should compartmentalise a load of code into a dll, I take it, its only useful in very large projects, and the code within is very generic????
 
how fine grained your dll's are are subject to the requirements and size of the project.

I'm been segmenting my dll's into
DAL, BLL, PAL and GUI.
DAL: auto generated code by my ORM tool
BLL: acutally 2 projects: Model (from ORM Tool), managers for the model
PAL: GUI agnostic presentation object (presenters and views)
GUI: asp.net

I have also developed a Common assembly.
this hold objects which can be used throughout different projects. I have a common assembly for BLL/PAL and another assembly with asp.net controls.

I have this as my current setup mostly because I'm forcing my self to learn better OOP practices.

this could also be a useful setup for large teams and/or projects with many moving parts.

this is just one way to setup seperation of duties.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
I'm doing a lot of work with the BusinessObjects XI SDK. My projects are organized so that all of the code that actually accesses BusinessObjects is in set of assembly .dlls - a "common" assembly that handles the connection and does some common translation of ID's to names and vice versa, and a set of "action" assemblies with one for scheduling reports, another for setting up users, etc. - and the code that uses them is in separate .exe's. Currently the code using the assemblies is for just one department. However, having this architecture means that we can reuse the assemblies for multiple departments as we bring them online into BusinessObjects.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top