In most of the MVC / MV* type frameworks I've played with they want you to have your source organized something like this:
model/
FooModel.xyz
BarModel.xyz
view/
FooView.xyz
BarView.xyz
controller/
FooController.xyz
BarController.xyz
organizing into directories based on the MVC elements rather than by the applications object types. Some part of me always feels like life would be easier if the code was organized like so:
Foo/
FooModel.xyz
FooView.xyz
FooController.xyz
Bar/
BarModel.xyz
BarView.xyz
BarController.xyz
Because in general, if I'm working on Foo (adding a new field for instance), I am often opening up all the Foo* files, which is tedious (first world problems) because all the Foo files are in different directories.
Is that a code smell that there is too tight of coupling between the Foo sources?
And of course, this alternative gets less appealing when we have models, views or controllers that don't have corresponding views, controllers and models. Which is often (usually?) the case...
So why is the standard organization for MV* frameworks actually better than my proposed straw man alternative?
I've been in the same dilemma myself. Looking in StackOverflow, What strategy do you use for package naming in Java projects and why? have some interesting insights, specially Uncle Bob's design principles for granularity. In the Common Reuse Principle he says:
THE CLASSES IN A PACKAGE ARE REUSED TOGETHER. IF YOU REUSE ONE OF THE
CLASSES IN A PACKAGE, YOU REUSE THEM ALL.
In the design package you mention, it makes perfect sense to have a model package, as is very common to reuse several Model classes through Controller and View Layers. On the other side, foo package can be hardly reused as is an application module itself. Also, according to the Common Closure Principle:
THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINST THE SAME
KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE
CLASSES IN THAT PACKAGE.
Several technlogy-related changes -like changing the JavaScript Library or the Dependency Injection Framework- will have minimum impact in model-view-controller packages (only one package should change) than in functional ones (the changes will span in all packages).
Not sure about other MVC frameworks, but for ASP.NET MVC specifically, the views should be in the Views/ folder.
One of the principles behind ASP.NET MVC is Convention over configuation. The view engine expects to find the views in a certain location. I believe you can override that, but it's generally better not to. (Use the convention)
I think the biggest problem with this file organization is cascading changes. If I need to add a field, I need to update 5 places (the model, the view, the viewmodel, the controller, the unit test). If you're digging around in folder trees to find these things, it can be tedious.
Maybe the question behind the question is 'How can I navigate through my solution artifacts more efficiently?' Again not sure about other IDE's, but since I use Visual Studio I've got my own set of preferences to help with that task.
In Visual Studio ctrl+, (control comma) is great for navigating to types/files/artifacts within a solution. Also I use F12 and Shift+F12 for 'goto definition' and 'find all references'. Also I customized the 'Find in Files' button to display image and text in the toolbar to make the button easier to hit.
Related
I have been using JGrasp for about 3 years which I am use to creating classes, Main classes, GUI classes which would be contained in the same folder in order to compile.
Now I started using NetBeans, and I pretty new to creating projects, creating the types of classes I will be using.
So my question is.. If i was to create a simple project which involves 3 classes, Person (super class), Employee (which inherits Person) and a Date class (which is associated with the Employer class).
I then also create a simple Gui interface on top of this class structure in order to take in details based on Person details and/or Employee details, and then a choice to display them on text area. The GUI contains 2 classes (UserDetails (takes in the details, and DisplayDetails (displays the details).
Would all this be contained into 1 project? And would the normal classes be contained a package different from the GUI classes?
Thanks, much appreciated.
With 5 classes, you can get by without a package structure. But you might aw well start thinking about a higher level of organization to your program code.
Put your data objects in one package--com.you.program.data
Put your GUI in at least one other package--com.you.program.ui
Main program could be in com.you.program or com.you.program.main or, if it is easier, just put the main in the UI package if its mostly just firing up the UI.
Note that com.you is, theoretically your webside backwards and 'program' is the name of the program you are working on.
NOTE
There is a theoretical discussion that goes on about whether to divide the business logic of the application from the UI that connects it to the user. Doing this makes it easier to put a different UI on the front of things and allow, for example, a Swing interface for users running on their desktops/laptops and a Web interface for users running browsers on their tablets and phones.
Its not a bad idea and one way to isolate that is to make two projects in your IDE. One holds the UI layer code and one holds the Business layer code. This is a well defined pattern and works well.
Another way to isolate the UI and business layers is to use packages but the IDE will not enforce any dependency management. But on a small project it does work well. You have to be disciplined. (And never forget how small projects grow into large ones with time and they do it unexpectedly.)
If you use projects, make sure there are no dependencies where the Business layer project uses the the UI layer without implementing a well defined pattern, perhaps an Observer (the GOF pattern). The UI layer, however, can and will be dependent on the Business layer. You can also enforce this during the stand-alone build process with a tool like Maven or Gradle, that excels at this.
No matter how you do it, you have to think about what is business logic. If you add some Javascript code to a browser or some code to a Swing GUI or a phone app to check that the phone number is a valid format for the country, its probably not going to bite you. If, however, you add code to the front end, in a similar way, that directly calls the phone number database to verify the first few digits are valid, you have stepped over the line. In those cases, that logic needs to be in the Business section and the UI part needs to call it to check that phone number. This is always a hard question to resolve with lots of edge cases.
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 :)
When structuring a visual studio solution I tend to structure it so that various components are in different project (As I would assume most people do) I tend to have a bunch of User defined exceptions.
The Question is should these exceptions be in a separate project to the (for example) Model classes?
I tend to put them in a sub-namespace of the model, and organise them in a directory within the Model project. but should they be in a separate project all together?
It depends on how you imagine them being used and how you deploy your application.
As a rule of thumb - never create more packages/assemblies than needed.
There's one strong case for putting Exceptions and Interface classes in their own assembly and that's when they're supposed to be shared among clients that not necesarily need to "full" package, one common scenario is when using remoting another is when building plugin architechtures.
Depends on how they're used I guess. If the exception is confined to a single project, put it there. If several projects use it, put it in a separate project.
I wouldn't bother as long as the message strings are configurable (properties file/xml). Having a generic top level interface would definitely help though, if the exceptions were to span across projects.