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.
Related
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 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.
What is the optimum number of projects in a Visual Studio 2008 solution?
We have one Visual Studio 2008 solution that is around 50 projects right now. It will likely continue to grow as the bulk of the projects within the solution consist of plugin assemblies for the main application.
If it seems like "too many projects" in one solution then how would you go about determining which projects should be grouped together in a solution? Given our example of approximately 50 projects in one solution with the bulk of the projects being plugins and with the number of plugins likely to grow, how should solutions be structured? Should all of the plugins be placed in their own solution? How should the organization change when the number of plugins in the plugins solution hits the magic number of "too many"?
We don't have any issues with this many projects in the solution ... it loads quickly, it builds quickly, it uses a reasonable amount of memory, and doesn't cause VS2008 to crash or bump up against any VS2008 bugs.
I've looked for documentation from Microsoft (there doesn't seem to be any) and Google searches yeild recommendations from "every project gets its own solution" to "place all projects in a single solution." Both extremes seem to be absurd. I'm looking for some reasonable guidance in the middle.
There have been other questions on Stackoverflow related to the maximum you've seen. That's not quite the same as what the optimum would be.
I'd say that you need at least 1 project for each layer on your system. If you need more projects, maybe it's a design problem. Meaning you can either "Over"-design or "Under"-design the application.
I nowdas use the following layers:
DataLayer - Responsible for the underlying data structure ( the database ). In the latest cases having the LINQ and partial classes for this in this project.
Interfaces - Having a layer for all interfaces, this to help extendabillity and not having to rely on some other layers to use these interfaces.
Logic - This defines itself, the business logic
GUI / Front - The Graphical user Interface ( Code )
These layers are the Minimum other Layers that COULD be possible would be Localization and other project that might grow.
But rahter simplify to directories and namespaces than using to many projects!
This is akin to discussions such as "how many functions should I have in a class?" and "should each enum be defined in its own .cs file?".
I would be interested to know how many classes each of your projects has. You can think of your classes, projects and solutions as organisational units. They are there to make your life easier, and to allow you (and your team) to break the overall project into managable conceptual chunks.
If VS2008 isn't complaining, and you and your developers have no problem with 50 projects in one solution then I would not worry about it.
That said, it does sound like a rather large number - but then we know nothing about the size of your overall codebase so it's hard to comment further.
Obviously when you get to 500 then you're starting to look at "too many" it becomes impractical even to manage it.
I might suggest that you analyse "what really constitutes my application" and package that as a single solution. Plugins are rarely considered part of the base application but add-ons to the base functionality.
If the application would cease to be useful without certain plugins, then include those in the base solution.
Other plugins might be grouped on Genre... much like the playlists on your iPod. What does each plugin achieve on a more general level? (These are obviously rhetorical questions) I would group plugins together in natural groups - much like PhotoShop plugins as they group on the menu. i.e. do they affect 3D, do they affect color, do they affect geometric effects, do they affect distortion etc etc.
When I see a slow down, I tend to create a solution that has references to built versions (assemblies) of dependent projects rather than the project files (for any projects that I don't need to see the source code). I only open the source for projects I am working on - surely nobody needs to work on the source of 50 projects at one time.
If you are already referencing the dependent assemblies rather than source, then I think it is just a matter or organizational preference (organize in a way that is easiest for you to understand and maintain).
I've seen a lot of different takes on this subject so I figured if there's a preferred way on this.
Is there any best practices on how to setup Visual Studio Projects and Solutions in regards to multiple solutions for the same solutions?
For example:
Let's say I have a task that calls for a web app, a console application, and a shared business logic library.
I have seen this situation in a 1, 2, and 3 solutions at some time in my career. This is a simple example; however, what if number of projects grows? Is there a line when to keep it in one or break it apart?
Indeed, there are some guidelines for this sort of setup on MSDN. I wrote a short summary in my answer to a similar question on StackOverflow.
I blogged about this back in 2007. The advice still holds:
http://mikehadlow.blogspot.com/2007/07/how-to-structure-visual-studio.html
The bottom line is that I should be able to get your code out of source control, open it in Visual Studio, hit F5 and everything should work.
Solutions are for the developer, in a particular situation. Projects (.CSPROJ for C-Sharp) are where the real compilation takes place.
Theoretically if there are 4 different projects, there could be 24 different combinations of those projects a developer may want to combine into solutions.
If you keep everything at a project level, you won't need to worry about how a developer has arranged their .SLN files
You can have multipe solutions, and each one can reference the projects that it cares about. Extending your example, your shared business logic library may have a corresponding unit test library. These two projects can be contained in one solution. At the same time, you may have another solution that contains the three projects that you mention, but in this case the unit test library isn't included.
My solutions typically consist of:
Web Application project
'Common' folder for base & common helper classes
'Include' folder
'Styles' folder
'Scripts' folder
'Images' folder
'UserControls' folder
Web Services project
Web Framework project
Business Tier project
Business Framework project
Data Access project
I like to include all projects for a certain task, in a solution. So based on the example you mention, I would have a solution containing the three projects that belong to the solution I was asked to do. That keeps all elements to complete a task together, I find this simplifies the inclusion of other elements required to solve the task at hand.