Visual Studio大型解决方案

Question

I've got a solution for my webapplication with almost 12 projects and 3 websites. There are some projects that I use for multiple websites like MyProject.BE / MyProject.BLL / MyProject.DAL / MyProject.Controls projects.

My question is, is it good to have multiple projects for BE/BLL/DAL/Controls, of is it better to create 1 project with folders for the BE/BLL/DAL layers?

Answer 1

The question of "large" is a relative one. In software development it is mostly a question of how good your PC is. If you can compile and run 100 projects in 1 second then 100 projects in a solution is "small". So it is really a question of what works for you.

My current work solution has about 130 projects in it. Yep, we could break it out but we have got some impressive boxes that can handle this so the cost of having 130 projects is moderate to low and advantages are bigger that the costs.

Having all of the projects in one solution is the go if you can compile, run, & test them all quickly. Darn ... that then starts the conversation onto what is "quick" and that is a style question. If you compile and run tests often (every minute or faster) then quick is seconds. If you compile and run every hour or so then minutes would be okay.

Answer: "Do what works for you".

Note: Consider solution folders.

Answer 2

I think it is indeed better to have multiple projects. If, for instance you need to build a WinForms UI that will use some of the existing classes in your BE and DAL layers all you need to do is reference those projects from the WinForms project.

Answer 3

As far as I have understoodyour question, you are referring to how-to-organize-a-solution rather than how-do-I-make-compiling-the-code faster or how-to-make-VS-open-my-code-quicker, right?

If so, I would say, break down your classes within the solution into multiple projects with names that make it clear what purpose they have. You already started an approach like that with the "BE/BLL/DAL/Controls" example you gave.

Having designated project give you lots of flexibility for how your solution architecture. Think about how much your solution may grow over time and for how long it may live in future. Think about how you will deploy it to the end users and - more importantly - how you will deploy updates. All these considerations should influence your decision how far you will go into details.

Analyse your code and check if there is potential to apply time-proven design patterns like Single Responsibility pattern.

Is it a short-term short-lived tool that runs a few times during development and never again? Then it would not be worth much effort. Is it a tool or application that will need to be maintained a few years? Then go and make sue that the SRP pattern is carefully implemented.

I recommend this book by Microsoft Press: Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern

This gives you some suggestions, recommendations and basics of how to build a good project structure.

Another suggestion of how a solution might be structured is in this SO thread: Mvvm Applications And location of Business layer