A large European company that has been trying to transition into VS.NET for about a year was having limited success. They have existing Java and Sybase applications and want to port them to the .NET framework. They spent the better part of 2005 rebuilding their management application on this new platform and found that when it was nearly "done", there were severe quality issues. The application could not be run for more than a few minutes before run-time errors would popup everywhere. No amount of band-aids seemed to help.
They were convinced that something had to be done differently. What they were doing was not working so they decided to do something drastic for a company: scrap our year's work, restart, and plan it this time. The first problem we found was that they were just trying to copy their database as-is to SQL Server from Sybase. This was an "evolved" database meaning there was very little planning. Tables were added when needed without consideration of what was there before, without indexes, without referential integrity, without planning in other words. There was duplicate data everywhere. We took their database and redesigned it in a proper fashion.
It was modeled in the Widgetsphere integrated environment. We have developed a set of database and WinUI templates over the last two years that allow us to use a well-designed database and create all data access code. The model generated the database scripts, stored procedures, views, selects, etc. It even created the install so that we can install this on a customer site.
This is a base foundation. The classes generated for data access provide a framework on which developers can expand functionality as needed. A framework makes it much more difficult to hack code and forces developers to think about the long term consequences of his actions.
In addition to data access, we also defined in the model what we call packages. A package is a software module independent of other modules. For example, you might have a Vendor package that has all the functionality to add, edit, delete, maintain, etc your company's vendors. Our package generator created the stubs of the package as the WinUI is highly specialized to your business. From there we can add custom code but the look and feel across the platform is uniform.
An added benefit of using packages is that by default the WinUI templates we used have a form that is used as an application shell and all "packages" are really snap-ins. Our templates do not force you to use this structure but it is generic and if used can speed along your application development. There is an add-in manager that "finds" package DLL files and allows you to snap them into your application or remove them. This allows you to email a new package DLL to your client and he can simply add it to the application's add-in list.
After the structure of the application was set we went about creating the Windows screens. This was made all the easier by the fact that most of the controls on screen can be bound to the API. Do not confuse this with data binding in the traditional sense. These controls like labeled textboxes, combo boxes, etc are actually generated and know about the database we have built. In other words a textbox knows that our model has a Vendor, Appointment, etc objects. It knows that when given a vendor object it will display the name, or address, etc. Probably 95% of all the controls can use this style of control creation. There will always be custom cases but since we offloaded a huge percentage of work, it made development that much faster.
The process was to drag a generated object named BusinessObjectBinder onto a form. One of its properties is the Business object to which to bind. Then we started to drag our special textboxes, checkboxes, combo boxes, etc onto the form. Each of these is pointed to our BusinessObjectBinder. Each control then needs to know what field of the BusinessObject to show and edit. Each control has its own displayed label that can be pulled from the model as well. It also will bind to only fields of the specific data type it supports. Textboxes will only bind to string fields; checkboxes to Boolean fields, IntegerTextboxes to integer; NumericTextBoxes to decimal fields, etc. This may sound like overkill, but there is a very good reason for this functionality. If you change the database the UI will not compile. Think about this. You cannot send your application to a user and get it to cause a run-time error because Field1 changed from a string to an integer. The VS.NET environment will give you a compile time error that you must fix to compile the application. This alone was a huge improvement to productivity since you must tweak the database from time to time.
The application ended up being about two million lines of code. There were another one million lines of stored procedures. This was virtually error free because if we found something that needed to be corrected, it could be changed in the model and regenerate. For example, when we needed to select data a different way, we did not need to go to a hundred stored procedures. We changed our template and regenerated to have new stored procedure scripts and also a new installation included! This was made even more impressive by the fact that the model was maintained by one person and completed in four months. Three million lines of code, 150 database tables, and a data access layer virtual error free in four months with a single software engineer.