Architecture/File setup for large project (Visual Studio)

Question

Back again.

At the moment we have a fairly large project coming up and we have had a few meeting's regarding design patterns/architecture/file set up etc..

During our last meeting I strongly contested against the proposed architecture/file setup and know I am unsure to whether I was just rambling and arguing my point just for the sake of it.

So the proposed was all projects sits under one SLN IE Data,Common,Business and UI. Obviously in a small application this would be great but considering this is going to be a large piece of software with 4-6 UI apps (all web apps). In Regards to the UI Project, there will be the Core UI (MVC) project with 4-6 apps nested inside the core MVC app using Areas.

My problem is, if the dll breaks, it will bring all of it down. My proposed would not have this affect as only the app with the most latest dll will fail.

I also perfectly understand that the SLN is a container of files.

Again this is not to discredit any of my colleagues but more just trying to get a wider knowledge.

Please see attached image and please let me know your thoughts.

Regards,

Tez

Answer 1

Generally speaking, if projects are not related to each other, than they should reside in separate solutions. If there are several exe-projects which share a lot of code, but they depend by their own on many (from three to n) projects which are not shared, than it can be useful to separate them. There is no a golden rule in my opinion about whether you should separate them or not. In the end it depends on factors you should evaluate by your own. Personally, I would separate exe-projects from each other if they are complex, say they are built in MVVM-style, when you have a bootstrapper for each exe, dll of views, dll of ViewModels, dll of models. Your solution could become quite polluted, if you put them in the same solution. And don't forget about .sln merges.