|Some background - I'm a contractor tasked to work on an ASP.Net Web Forms app that is part of a larger suite of apps. When I was hired, I was told that I would have the opportunity to rewrite the app I had the desire. What they didn't tell me is that the nature of the app suite pretty much precluded me from doing so. So me, not willing to accept defeat so easily...
What I'm Doing:
The other devs have been "resistant" to a rewrite, and understandably so. It would feature unfamiliar (albeit, more modern) technology, most of the every app would have to be re-implemented and re-tested, and there simply isn't enough time/people/resources available to support the effort. I think if they allowed one day per week for everyone to work on this, it could be done in a reasonable period, and once it gather a notable head of steam, it could replace the current maintenance effort currently allocated to the legacy code base. Beyond that, everybody in the group has a life/family/interests that do not include putting in the extra time necessary for doing a rewrite. Everyone except me.
With all of that in mind, I decided to embark on an un-tasked effort (on my own time, at home) to come up with a project template we can use to easily create new apps that have no dependency on each other, support our complex database and web server requirements, and provide common functionality that all of our apps must have.
0) Our suite of apps can exist in one of five environments - Dev, Test, QA, Prod, and None (a special environment that I use at home for working on the prototype). Each environment can be run on one of two networks - classified and unclassified.There are almost 20 applications, each with their own database, and each of which share two of those database. Each app can also optionally access any of the other databases as needs are determined.
1) All of the applications must use the same presentation style, and identifying components, such as a header panel that displays the app name and an appropriate graphic, a bar that illustrates the environment (locked at the top and bottom of the screen), access to app info and help desk/point of contact info, and display the connected user.
2) The site uses Entity Framework. This is NOT by choice, but since the authentication stuff uses it, I figured I may as well, too. This has been my largest hassle to date, because I generally don't like EF, and ALL of our database access is handled by stored procs, which means we have to do things (apparently) wildly different from how EF thinks we should.
0) I have the layout requirements ironed out. The only thing they have to provide in a new application is the app-name graphic that's displayed in the header banner, and provide (or select) the desired background image used in the banner.
1) The startup process begins with checking whether the site is in maintenance mode. If it is, a special div is presented, and processing stops. If it isn't in maintenance mode, the site attempts to use the user's CAC card to log him in, and if the CAC isn't found, the user is prompted to login manually. Once the user logs in, his login history is presented, and when he clears that form, the site begins its normal functionality (presenting the app's menu and taking him to the home page).
2) The entity framework stuff was a veritable nightmare, mostly because I wanted to put all of the EF code into a separate assembly into which the developer could add what he needed. As it sits, the DataModels assembly already includes one model that allows the app to determine how certain aspects are present. All the developer has to do is add his own contexts and models, using the
ADO Data Entity Model template provided in Visual Studio. This was made quite problematic due to our 20 apps in five environments (100 possible connection strings) requirement, as well as the desire to have all of the possible permutations of the connection strings be completely contained in code. This forced me to write a class that configures the connection strings base on the specified application and environment so that only the connection strings the app needed were created. This further caused the creation of a couple of static classes that would be available site-wide, which also solved the "use a model in a shared view" problem.
So, the prototype currently eliminates at least a week's worth of development, even for an experienced MVC/EF developer, is copiously commented, and even has a dedicated HTML page that the developer can reference when he needs to know where stuff is and why it was done.
No existing code was harmed in the making of this movie. I think I'm almost ready to show off my baby to the other devs on the team.
I've been busy.
PS. Even if it's not implemented and my efforts are criticized/ignored, I will at least be able to lay claim to making the effort to positively affect the code base, and I will have learned a lot in the process, besides. There's no such thing as "wasted effort" if you learn something along the way.
PS.PS. I might even make a video demonstration (on youtube) so they can see the project template in use.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013