I was wondering if anybody could give me a few pointers on designing a large solution.
We have a rather large application written in a legacy codebase that we are rewritting from the ground-up in C# 2.0. One of the problems I constantly face is the fact that I would like to break things up into separate projects to group common things together but then I always face the problem of "circular references".
Can some of you folks who are developing large applications give me some insignt in how you structure your solution(s) I have thought about having separate solutions, but that seems to defeat the purpose of having multiple projects in the same solution!
Here's one example of a problem that I face. I want to segregate all my security junk into a separate project/DLL. The security junk has to hit our DB to pull data [to get a list of modules installed, etc. etc.] My printing engine [separate project/dll] needs to check security on certain stuff and also needs to access the DB. Last, all of my DB access is processed through a separate project/DLL as well [I've written a rather extensive data layer]. If I do this, its a circular reference... I can reorganize it, but I am unsure as to the "best" way.
Thank you very much for any ideas that anybody can provide!!

Solution Design?
preethi_rjs
I agree with the layer comment.
I would also recommend considing using facades to sepereate out subsystems and reduce
the interdepedancies between projects.
Not sure I see the circular reference in your example:
(note to Microsoft, how about the ability to sketch diagrams..)
Security ----------------> DAL
^ ^
| |
| |
Printing -------------------------
This is not a circular reference
My best advice would be not to let it get out of control over time during the maintenance phase of the project.
Use something like the NDepends tool which draws your dependancies to give you a good picture.
Regards
Ed
fhunter
Hi, one of the ways to avoid circular dependencies is going for a layered approach for your application architecture.
try to first design your layers with most independent block on the bottom layer. e.g. your db layer. May be then you can have one sloution for each layer.
http://DotNetWithMe.blogspot.com
vikas goyal
Blackwood
Thank all of you very much for all of your information.
I had already started to entertain the idea of separating various pieces into separate solutions, I just really like the one solution concept because of the level of flux of the project. I think I will take your various ideas into consideration and separate the projects into separate solutions and use NDepends to reduce the amount of inter-dependancies [which, after running it on the current solution, showed me that the whole thing is VERY interdependant!]
John.
cbpd86
The book I suggest you isn't surelly the last word in terms of Application Architecture but is pretty understable
It's name is "Application Architecture for .NET: Designing Applications and Services" and his author, Edward Jezierski, told me recently that he's working in an updated version. That book suggest a holistic approach that I'm confident it fits in the 80% of cases (citing Paretto's law)
Some other non Microsoft book include:
Finally, don't stop visiting the Microsoft's Architecture Center, and specially the Modeling and Tools page
And the Golden rule: be pragmatic. Apply counsels and guides when they supply clearly benefits for you and your project. Don't act in any manner just because "it must be done such way". You'll avoid early frustration
poruchik_rzhevsky
I have to agree with that.
Also, if problems still persist, you could use abstract classes and interfaces in a separate Dll project. I've done this for a large search application where there are several circular references, and managed to clean up so that now I actually have a complete plugin framework.
If you have questions about all this, please just ask away.