One of the best things about Fred’s UltraBase code generator is that it really pushes the boundaries of what’s possible in C#. The first couple of times I tried to open the ProductDomainMapper class is actually crashed my IDE. After disabling every extension I had I was finally able to see the code. I’m still not entirely sure why Visual Studio was crashing, but I think it may have something to do with the 92 interfaces declared on the class:
public partial class ProductDomainMapper : BaseDomainMapper,
In case you were wondering what all these interfaces did, here is the complete implementation of one of them:
public IResponseDTO<AmountCategorySelectData> Select(IRequestDTO<AmountCategorySelectInput> input)
var mapper = DataMapperFactory<ISelect<AmountCategorySelectData,AmountCategorySelectInput>>(DataMapperEnum.AmountCategory,BehaviorTypeEnum.Select);
if (mapper != null)
And no code sample would be complete without showing how the code is called:
var mapper = new ProductDomainMapper();
var input = new RequestDTO<AmountCategorySelectInput>();
input.Input = new AmountCategorySelectInput ();
input.Input.SortAscendingFlag = 1;
IResponseDTO<AmountCategorySelectData> result = mapper.SelectByCode(input);
Last time we introduced Fred and his UltraBase. The UltraBase wasn’t a production application, but rather a sophisticated code generator that would be used to create the middle tier that would be shared by all hundred or so applications used by SmallCo. Unfortunately it had some limitations that couldn’t be overcome.
One of the biggest stumbling blocks for the middle tier/website team is optional parameters on stored procedures. SmallCo often wrote procedures in which a given parameter may be used by some applications and ignored by others. The convention was quote inconsistent; sometimes the optional parameter would have a default value, other times a null would have to be passed in.
The website was the first application to start using the middle tier. Since it had limited functionality compared to the internally facing applications, it more than others ignored a lot of parameters on the stored procedures. When they saw this, Fred’s team became very concerned. Since they weren’t sure they could properly test web service wrappers around the stored procs, they decided that all of those parameters the website didn’t use wouldn’t be available via the middle tier either.
Unfortunately the UltraBase didn’t support skipping parameters, nor did it support defaulting them to null. So after much arguing, and a near revolt by the database team, it was decided that Fred’s team would create roughly 200 stored procedures that simply wrapped the real stored procedures and hid the optional parameters.
I still wonder what they plan to do when asked to wrap the other 7,400 stored procedures we currently use.
Like many financial companies, SmallCo had a large stable of applications. The most important of these was a very large Visual Basic 6 application that most of the sales and trading teams used. There were also dozens of small .NET applications that did back-end processing and a website used by a handful of customers that didn’t want to talk to a salesman. Since SmallCo had a tiny IT department and almost no testing budget it relied on quickly change applications even during the middle of the business day. A key part of this strategy was by putting most of the business logic into stored procedures.
This plan worked surprisingly well for a long time, but eventually SmallCo started to evolve into LargeCo. LargeCo’s business model couldn’t tolerate the frequent break-downs and emergency fixes that were part of day to day life at SmallCo. In addition, having all of the business logic in the database was causing them to purchase larger and larger databases until they reached the point where upgrades simply were not feasible. Something had to change.
Fred was hired to make this change. His mandate was to create a middle tier accessible by all applications. All stored procedure calls would go through this middle tier, and over time the logic would be pulled out of the procs and moved into the middle tier itself. The process would start with the website, which was reasonably manageable and was scheduled to be replaced eventually anyways.
To make the process easier, Fred and his team created the UltraBase. The UltraBase was sold to management as just a code generator. Developers would record all of the stored procedure names, parameters, and result sets in the UltraBase’s configuration database and out would pop the middle tier. They could then start the process of moving the business logic out of the database.
After six months of development, the process of calling a stored procedure became this:
Note that at every assembly below website is 100% code-generated. Even the configuration database is code-generated from another database. Absolutely no hand-written code is allowed in the middle tier. If something cannot be expressed using the UltraBase’s configuration tables it had to be moved up into the website or down into the stored procedures.