Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
When spliting a solution in to logical layers, when is it best to use a separate project over just grouping by a folder?
By default, always just create new folder within the same project
You will get single assembly (without additional ILMerge gymnastic)
Easier to obfuscate (because you will have less public types and methods, ideally none at all)
Separating your source code into multiple projects makes only sense if you...
Have some portions of the source code that are part of the project but not deployable by default or at all (unit tests, extra plugins etc.)
More developers involved and you want to treat their work as consumable black box. (not very recommended)
If you can clearly separate your project into isolated layers/modules and you want to make sure that they can't cross-consume internal members. (also not recommended because you will need to decide which aspect is the most important)
If you think that some portions of your source code could be reusable, still don't create it as a new project. Just wait until you will really want to reuse it in another solution and isolate it out of original project as needed. Programming is not a lego, reusing is usually very difficult and often won't happen as planned.
denny wrote:
I personally feel that if reusable code is split into projects it is simpler to use other places than if it is just in folders.
I really agree with this - if you can reuse it, it should be in a separate project. With that said, it's also very difficult to reuse effectively :)
Here at SO, we've tried to be very simple with three projects:
MVC Web project (which does a nice job of separating your layers into folders by default)
Database project for source control of our DB
Unit tests against MVC models/controllers
I can't speak for everyone, but I'm happy with how simple we've kept it - really speeds the builds along!
Separating features into projects is often a YAGNI architecture optimization. How often have you reused those separate projects, really? If it's not a frequent occurrence, you're complicating your development, build, deployment, and maintenance for theoretical reuse.
I much prefer separating into folders (using appropriate namespaces) and refactoring to separate projects when you've got a real-life reuse use case.
I usually do a project for the GUI a project for the business logic a project for data access and a project for unit tests.
But sometimes it is prudent to have separation based upon services (if you are using a service oriented architecture) Such as Authentication, Sales, etc.
I guess the rule of thumb that I work off of is that if you can see it as a component that has a clear separation of concerns then a different project could be prudent. But I would think that folders versus projects could just be a preference or philosophy.
I personally feel that if reusable code is split into projects it is simpler to use other places than if it is just in folders.
I really think it is better to split the project as well, but it all depends on the size of the project and the number of people working on it.
For larger projects, I have a projects for
data access (models)
services
front end
tests
I got the model from Rob Connery and his storefront application... seems to work really well.
mvc-storefront
Separating your source code into
multiple projects makes only sense if
you...
... More developers involved
and you want to treat their work as
consumable black box. (not very
recommended) ...
Why isn't this recommended? I've found it a very useful way to manage an application with several devs working on different portions. Makes checkins much easier, mainly by virtually eliminating merges. Very rarely will two devs have to work on the same project at the same time.
If you do go for creating several projects, make sure everyone who adds code to the solution is fully aware of the intention of them and do everything you can to get them to understand the dependencies between the projects. If you have ever tried to sort out the mess when someone has gone and added references that shouldn't have been there and got away with it for weeks you will understand this point
Related
I have my first CQRS project which uses event sourcing and I was wondering if this type of project should be structured in a different way in Visual studio compared to other projects that involve multiple tiers?
For example, in the pastt projects created had layers such as Remoting, App services, domain etc and it was clear each layer/assembly touched the one below it. These assemblies seemed to do a lot and using a tool like NDepend did say much about the structure of the project.
However, with a CQRS project would it be better just to have smaller assemblies that show their intent i.e. assembly for commands, another for events, another for event handlers etc.
Now with NDepend it would give me a better representation how the assemblies are used.
I generally structure my CQRS projects with smaller projects that are descriptive of their intent -- Command, Domain, Event, Denormalizer, Repository, Command Service, etc.
It makes it much easier to navigate through your solution this way, and also makes it easier for others on your team (or new team members coming on board) to work with the various components of your system.
Also, if you have a team working on this, you can easily let one group focus primarily on the domain project (probably your higher-end team members) while your junior members could work on the denormalizer project.
You'll end up with (probably) more projects, but they'll be smaller chunks and much easier to understand their purpose. Kind of like the Single Responsibility Principle, but at the project level.
Hope this helps. Good luck.
I seem having difficulty in understanding the reason behind the need of having many projects inside one solution (in my case visual studio 2010 with c#).
The only use that comes to mind is if I am creating a new classes I can test them in a console application first, then add another project to the solution to use these classes with the project that I want.
kindly guide me to the correct way, thanks.
A typical project might have a UI, a data layer, a services layer, and a domain layer, as well as some tests. A typical arrangement would be for each of these to exist as their own project file. The solution would contain all of these projects so that you can make modifications and debug different parts of the app at once.
If you're just starting out, you probably cram all of this stuff into one project. That's fine for learning, but is an absolute mess for maintainability and reusability.
There are 3 main reasons that immediately come to mind for splitting your solution into multiple projects: Reuse, Encapsulation, and Project-specific settings.
Reuse
You may have a Utilities project that is shared between more than one solution. You may also have data access and business rules that are defined in class libraries, but are shared between multiple UI projects, such as having a business application that has a web interface, a desktop interface, and web services. They all need to share the same logic and data model, so you wouldn't want to replicate it in each solution separately.
Encapsulation
Another reason is to achieve encapsulation, one of the main principles of OOP. Your classes may have internal methods and properties (or the classes themselves may even be defined as internal), which makes them only visible to other classes in the same project. If it's there to achieve a specific purpose but not something that should be accessible to all, by splitting your classes across separate projects you can make those properties, methods, and classes visible to your classes, but hidden outside the scope of your project.
Project-specific settings
There are certain project types that behave completely differently from one another. A Web Project is different from a Windows Forms app, which is completely different than a WPF app. This kind of goes along with #1 and trying to achieve code reuse; since you can't have a single project that is a website AND a Windows Forms app AND a WPF app, you create each UI as its own project and put as much logic as possible into a separate project that can be shared between all of the UI projects.
A couple possible reasons off the top of my head:
a project may be useful in more than one solution
simple organization utility - just like you might have classes in separate files even though a single source file can hold multiple classes just fine.
There doesn't seem to be any tried and true set of best practices to guide you on how to setup your solutions, projects and the assemblies they output. Microsoft seemed to have tried back in the VS.net days, but they have since retired this content. For every method I read about I read another that claims the opposite is better, or a post that only concerns itself with "if only Microsoft would..." but really provide no solutions.
It appears there are many ways to do this that all seem to work for various groups in their situations, therefore I thought I would ask what conventions YOU use and why they work for YOU in your situation.
I hope that this will provide several good conventions for different situations, small development groups and projects to large diversely located development groups and projects.
What conventions do you use to...
name your solutions, and why?
name your projects, and why?
name your assemblies, and why?
know when to create a new project or add to an existing project, and why?
know when to split up a solution into smaller solutions, and why?
know when to break up a project into multiple projects, and why?
Just to be clear, the WHY is just as import as the HOW in these answers. There are many answers posted on the how here and other places, very few say why they use one convention over another.
That's a very broad question, but a good one. I will start with a simple structure that I use for ASP.Net web projects (MVC will look completely different).
Solution naming isn't a big deal to me. I tend to create solutions for a specific purpose, and add existing projects to the solutions. If your solution is over 15 projects (just a rough number) consider adding some of those projects as references. Most people don't need to work on more than 15 projects at a time.
Project Naming is a big deal to me.
// class library that supports the site itself and abstracts
// more complicated UI logic into a separate place
Company.ProductName.Web;
// website
Company.ProductName.Web.UI;
// main business object library for product
//
// of course, you can have as many of these as needed.
Company.ProductName;
I try to use enough folders in my projects so that all files in a folder can easily be viewed without scrolling the solution explorer.
My typical web project looks something like this. Note the different in casing to represent namespaced/compilable resources versus those that are not.
client (css, javascript)
config (private, custom config files, if any)
Content (Master Pages, ASPXs and ASCXs, broken into logical folders)
Handlers (ASHXs and such)
images
MSBuild (build scripts)
WebServices (these should ONLY be small services that are directly related to the site in question. Otherwise, break them into a separate project).
I've started using partial classes more and more to create comprehensive classes that can do many things without having the code be cluttered. For example, I recently created a web service whose single purpose is to return JSON to the client, but the logic is spread across almost a dozen partial classes to organize it better.
Hope that gets you started.
In our case we keep our project names quite identical to namespaces that we chose for particular assembly. That way it becomes easy to map location of a class file in physical folder. For example - CompanyName.BusinessLine.BusinessService or CompanyName.Framework.Security. So if a developer is looking at CompanyName.Framework.Security.Cryptography.cs, he can immediately figure out the project and open that project.
As Tim says, this is very broad. A few things to note:
A solution is usually just a collection of projects. Many solutions can include the same projects, for example. As such, it doesn't matter too much: if you don't like a solution name, you can throw it away with no refactoring at all.
Like Pradeep, I tend to name projects with the top level namespace they contain. "Deeper" namespaces end up in subdirectories, so classes within the Foo.Bar.Baz namespace might be in the Baz directory of project Foo.Bar.
I tend to split into projects across:
Elements of reusability (e.g. one assembly for a UI, one for a reusable set of model classes, one for a reusable general purpose utility classes)
Elements of deployment (e.g. one for production, one for testing, in pairs)
Elements of reference (e.g. if you have a common assembly Skeety.Common with some interfaces used by other classes, there might be a Skeety.Common.Testing assembly containing types which help you to test classes using Skeety.Common). This leads to these rules:
Production assemblies can only refer to other production assemblies
Testing assemblies can only refer to production assemblies and other production assemblies
Test assemblies (the ones containing the tests themselves) can only refer to production and testing assemblies, not to other test assemblies
No circular references are allowed, obviously
In many cases it actually doesn't matter too much how you split things up - but it does help to make the design cleaner as you work out the dependency layers (so a business logic assembly shouldn't have a reference to a UI assembly, but vice versa is fine).
Having too many project can definitely slow you down, both in terms of build times and just working out where everything should be. Having too few projects makes the design less clear. Over time you're likely to get more of a gut feeling for how things should be laid out - but I'm blowed if I'd claim to always know the best course of action :)
I see developers frequently developing against a solution containing all the projects (27) in a system. This raises problems of build duration (5 minutes), performance of Visual Studio (such as intellisense latency), plus it doesn't force developer's to think about project dependencies (until they get a circular reference issue).
Is it a good idea to break down a solution like this into smaller solutions that are compilable and testable independent of the "mother" solution? Are there any potential pitfalls with this approach?
Let me restate your questions:
Is it a good idea to break down a solution like this into smaller solutions
The MSDN article you linked makes a quite clear statement:
Important Unless you have very good reasons to use a multi-solution model, you should avoid this and adopt either a single solution model, or in larger systems, a partitioned single solution model. These are simpler to work with and offer a number of significant advantages over the multi-solution model, which are discussed in the following sections.
Moreover, the article recommends that you always have a single "master" solution file in your build process.
Are there any potential pitfalls with this approach?
You will have to deal with the following issues (which actually can be quite hard to do, same source as the above quote):
The multi-solution model suffers from
the following disadvantages:
You are forced to use file references when you need to reference
an assembly generated by a project in
a separate solution. These (unlike
project references) do not
automatically set up build
dependencies. This means that you must
address the issue of solution build
order within the system build script.
While this can be managed, it adds
extra complexity to the build process.
You are also forced to reference a specific configuration build of a
DLL (for example, the Release or Debug
version). Project references
automatically manage this and
reference the currently active
configuration in Visual Studio .NET.
When you work with single solutions, you can get the latest code
(perhaps in other projects) developed
by other team members to perform local
integration testing. You can confirm
that nothing breaks before you check
your code back into VSS ready for the
next system build. In a multi-solution
system this is much harder to do,
because you can test your solution
against other solutions only by using
the results of the previous system
build.
Visual Studio 2010 Ultimate has several tools to help you better understand and manage dependencies in existing code:
Dependency graphs and Architecture Explorer
Sequence diagrams
Layer diagrams and validation
For more info, see Exploring Existing Code. The Visualization and Modeling Feature Pack provides dependency graph support for C++ and C code.
We have a solution of ~250 projects.
It is okay, after installing a patch for Visual Studio 2005 for dealing fast with extremely large solutions [TODO add link].
We also have smaller solutions for teams with selection of their favorite projects, but every project added has also to be added to the master solution, and many people prefer to work with it.
We reprogrammed F7 shortcut (build) to build the startup project rather than the whole solution. That's better.
Solution folders seem to address the problem of finding things well.
Dependencies are only added to top-level projects (EXEs and DLLs) because, when you have static libraries, if A is dependency of B and B is dependency of C, A might often not need to be dependency of C (in order to make things compile and run correctly) and this way, circullar dependencies are OK for compiler (although very bad for mental health).
I support having fewer libraries, even to the extent of having one library named "library". I see no significant advantage of optimizing process memory footprint by bringing "only what it needs", and the linker should do it anyway on object file level.
The only time I really see a need for multiple solutions is functional isolation. The required libs for a windows service may be different than for a web site. Each solution should be optimized to produce a single executable or web site, IMO. It enhances separation of concern and makes it easy to rebuild a functional piece of the application without building everything else along with it.
It certainly has its advantages and disadvantages anyway breaking a solution into multiple projects helps you find what you looking for easly i.e if you are looking for something about reporting you go to the reporting project. it also allows big teams to split the work in such a way that nobody do something to break someone else's code ...
This raises problems of build duration
you can avoid that by only building the projects that you modified and let the CI server do the entire build
Intellisense performance should be quite a bit better in VS2010 compared to VS2008. Also, why would you need to rebuild the whole solution all the time? That would only happen if you change something near the root of the dependency tree, otherwise you just build the project you're currently working on.
I've always found it helpful to have everything in one solution because I could navigate the whole code base easily.
Is it a good idea to break down a solution like this into smaller solutions that are compilable and testable independent of the "mother" solution? Are there any potential pitfalls with this approach?
Yes it is a good idea because:
You don't want VS to slow down on a solution with dozens of VS projects.
It can be interesting to only focus on a portion of the code, this enforce the notion of code locality which is a good thing.
But the important first thing to struggle for is to have as few VS projects/assemblies as possible. My company published two free two white books that explain the pro/cons of using assemblies/VS project/namespaces to partition a large code base.
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)
The first white-book explains also that VS is pretty slow when working with a solution with dozens of projects, and shows tricks about how to remedy to this slowness.
I am the intranet developer for the company I work for and I have been doing this for the last 5 years. My projects are divided into two solutions, the "Intranet" solution itself and the "Library" solution. The "Library" sln itself has several projects containing the DAL, BLL, etc.. The reason why I kept them in a different solution is because I thought that "maybe", one day my library sln can be used in other projects as well - you know reuse the code that I already wrote :) Well, that never happened. Now, since its so easier to have all projects in the same .sln, I am thinking to just do that. Is that a wise situation? What would you do if you were in my shoes?
In the past I've used and reused the same 'project' in multiple solutions - I really just see a solution as a 'particular' instance of a collection of projects.
For example, we might have different solutions for the same overall piece of software depending on whether we want to be doing unit testing (in their own project) and or integration testing (in a separate project), and we'd open the right solution for what it is we're about to do. That way if you're doing normal coding with unit testing you don't have to build the integration test code every time and visa-versa.
Only thing to watch out for is bringing in a project to a solution that is a dependency of lots of other projects/solutions and then "accidentally" changing the code in it without realising it's in a side project rather than your main code. Then you can start breaking loads of other projects that depend on it and not realise!
Yes, you can do it! You may still reuse your DAL and BLL, as the project settings are stored in the specific project files (csproj, vbproj, ...). Also dependencies are stored there, so no problem and good to go. I have an addin-infrastructure and for every and each addin-package, I do need the addin-host, which is included in several solution files. I never experienced any problems with this. Open up your *.sln file in a text-editor to see its contents...just links to the projects.
Simply add your library projects to your intranet sln. Keep your library solution as is.
I would personally all add them to the same solution, yes. Namely, it doesn't matter if you plan on using some of the libraries in the solution in other projects: you can still add the compiled dll to those solutions, or you have the option to add them as an exisiting project to the new solutions.
So yes, I add everything to the same solution: gui-projects, libraries, even unit tests. Maybe if your solution becomes incredibly large (20+ projects, or larger) it would be better to split them up, but I've never worked on such large projects.
I prefer to have 2 solutions. They both have identical structure (more or less) but the 2nd contains reusable infrastructure code only that isn't tied to a particular project. The thing is - your project code shouldn't contain framework-like (i.e. 'IsNumeric()' string extension method) stuff next to serious banking business logic (even if you won't reuse your 'Library'). That just makes things much more readable and maintainable.
For example:
Solution1:
ProjectName.Core
ProjectName.Infrastructure
ProjectName.Application
ProjectName.UI
ProjectName.IntegrationTests
ProjectName.UnitTests
And
Solution2:
CompanyName.Core
CompanyName.Infrastructure
CompanyName.Application
CompanyName.UI
CompanyName.Tests
And I try not to have more than 10 projects in 1 solution. Otherwise - it leads to infinite toggling between "unload project"/"reload project.
I, for my part, have separated the Solutions and the projects, leaving me with a big punch of projects and only a few solution-files. I add all the projects I need in new solutions.
The upside is that I only have the projects in my workspace which I really need and it still changes in all other solutions.
The downside is that it changes in all other solutions too, means that if you change the API of a widely used library, you'll have to check all your other solutions if incompatibilities.