To this day it puzzles me that the most important organizational decision that you can make is so often overlooked. Whenever I bring up the importance of naming and proper organizing of projects and namespaces, I get scuffed at. And who out there really knows what the RIGHT way is? I say I don’t but I have a vague idea of what the right way will be for Lunchage, at least till “new shit comes to light”.
There are two main points that need to be addressed. One is the number of assemblies should be kept to an minimum. Two is proper naming of namespaces and classes.
In my experience improper seperation of projects and namespaces is one of the biggest downfalls of any project. As the number of projects grows, two negative consequences inexplicably happen. One, compilation times shoot up to 2 to 5 minutes per build. Plus the just in time compilation of ASP.NET adds another 2 – 5 minutes. Thus if a developer compiles code 50 times in a day, then you are looking at a 100 to 250 minute time waste. Two, traversal and searching for classes becomes a burden. Sure with the lovely “Ctrl-T” in ReSharper I can quickly go to the class, but find usages becomes a 2 minute wait of checking every project. And if you are just browsing the code to get familiar with the application, well good luck and bring a lot of patience.
Minimize the number of assemblies!
Shrinking the number of assemblies down to one or two is the best thing you can do! There a few WEAK arguments for multiple assemblies, but they all fall short when inquiring more deeply about application of such methods. Don’t tell me about your hypothetical situation where monkeys rule the world.
Don’t use IRepository!
Raise your hand if you understand what Repository really means. Now put them down if you ever have a Repository with any kind of load planning. Repositories do not have load planning! Repository from P of EAA and Repository from DDD have nothing in them about load plans and the depth of objects loaded. By my interpretation the object returned is a fully hydrated object plan that does not need further database query. Using ORM tools such as NHibernate we can remove the full hydration by having lazy loading. But when you start going down that path, remember that it leads to hundreds of database queries just for a single action. I bring up the Repository naming because of its misuse, and:
You must have a Common Language!
Just like we agree on the meaning of English words, we must also agree on the meanings of what we name classes and namespaces. Also if you do have a Repository feel free to use the name, and be ready to accept the consequences of following the pattern whatever it entails. Design patterns are one part of the whole of common language for programming. This common language is programming language agnostic and spans operating systems and ignores syntax. This language is also rooted in good programming practices, SOLID principles, and design patterns.
Starting an application with a proper naming structure and organization will save you time and sanity in the long run. If you don’t have the luxury of starting from scratch, then bring your solution up to date, spend some time organizing and cleaning up, you will not regret it!














