Database Project Entropy
With every new release of a software product, some features are altered at the request of the majority of users with the aim to improve the product. And generally these changes are correct. Most, but not all. Some are short sighted at best. And if there was one feature change which Microsoft acquiesced to which I just cannot abide by was to remove the automatic creation of the folder structure in Visual Studio database projects.
It’s bad enough that they totally did away with it rather than make it opt out, but what really grinds my gears is that all new objects are created in the root location. So now everything can be found in one place, with just the one small problem of having to search through everything else. Folders can now be created at the developers discretion, or they can keep a single long list of files at root. There are so many reasons why I think this is a bad idea
[caption id=“attachment_2522” align=“alignnone” width=“400”] Now where did I put that view?[/caption] hybrid structure; most projects I’ve dealt with have been imported from a previous version of Visual Studio, and IIRC you could define whether you wanted to keep the structure. I opted to keep the structure, but now certain developers have realised that structure is no longer necessary, so they just started creating files at root filled with creating files/filegroups and partition functions/schemas etc, but left the rest of the objects in the structure. This is worse than point 3 beacause rather than confusion causing inconsistency, this is laziness causing inconsistency and confusion. It’s infuriating to pick apart a labyrinth of object declaration and slows down actual work in place of boring maintenance of the project which no one wants to do
w/r/t the 2nd point you do indeed have a list of files at the root of a project for C#. The big difference here is that developers are far more likely to navigate using namespaces than solution explorer, and so the structure is far less significant. In SQL Server Management Studio, the structure is much the same as what it was in the old database projects, so really it makes even less sense to not at least follow the structure that you have in SSMS.
Now I do understand that the folder structure was complex, even for the most basic of database projects, and that at it’s worst the structure was a “one size fits none”, but I’m not convinced that no structure is better than one structure that’s complex and rigid.
The best cure for a hangover is to never drink in the first place: By making folder structure an option we’ll end up with a hangover every morning we work on the project. Some of you may disagree with me and I’ll be interested to hear your points below.