API's that Suck

January 3, 2011

The Story of UltraBase: Chapter 4

Filed under: UltraBase — Grauenwolf @ 8:35 pm

Fred didn’t like project references. In fact, he absolutely hated project references. So when he started on the middle tier he made sure his team only built their project using assembly references. Moreover, those assembly references all had to point to the golden location, a shared drive where releasable code was posted.

In some cases this makes a lot of sense. Especially when the purpose of each assembly is clearly delineated and low level assemblies are completely unaware of the assemblies that use them. But this situation is a little bit different.

To start with, you need to know about the six assemblies that make up the middle tier. From highest to lowest they are the Adapter, Core, BusinessLogic, DAL, Config, and Data libraries. Each library builds upon the ones before it. For example, in order to add a UserSearch function to the Adapter and BusinessLogic layer you must first add a UserSearch entry to the DataMapperEnum found in the Data Library. And all of the parameters must exist on a UserSearchInput object found in the DAL assembly.

I’ll walk you through the process. First get the UserSearch stored procedure from the database team. Then enter in its name, parameters, and output columns into the UltraBase configuration database. Since databases don’t really work with source control, make sure you kick off a backup.

Open up the Data libraries solution and update the version number. Kick off the code generation process, and then check everything in.

Once the build machine is done, copy the new version of Data into the golden location. Then open config library and update its version number. Change its reference to point to the new version of Data, regenerate the code, and check it in.

Once the build machine is done, copy the new version of Config into the golden location. Then open DAL solution and update its version number. Change its reference to point to the new version of Config and Data. Regenerate the code and check it in.

Once the build machine is done, copy the new version of DAL into the golden location. Then open BusinessLogic solution and update its version number. Change its reference to point to the new version of DAL, Config, and Data. Regenerate the code and check it in.

Once the build machine is done, copy the new version of BusinessLogic into the golden location. Then open Core solution and update its version number. Change its reference to point to the new version of BusinessLogic, DAL, Config, and Data. Regenerate the code and check it in.

Once the build machine is done, copy the new version of Core into the golden location. Then open Adapter solution and update its version number. Change its reference to point to the new version of Core, BusinessLogic, DAL, Config, and Data. Regenerate the code and check it in.

Once the build machine is done, you can deploy the new version of the middle tier.

Once the build machine is done, copy the new version of Core into the golden location. Then open Adapter solution and update its version number. Change its reference to point to the new version of Core, BusinessLogic, DAL, Config, and Data. Regenerate the code and check it in.

With all this done, you can change your website code to use the middle tier.

December 30, 2010

The Story of UltraBase: Chapter 3

Filed under: UltraBase — Grauenwolf @ 8:35 pm

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,
    ISelect <AmountCategorySelectData,AmountCategorySelectInput>,
    ISelectByCode <BondOfferingSystemServiceModelSelectForRepData,BondOfferingSystemServiceModelSelectForRepInput>,
    ISelect <BondQualitySelectData,BondQualitySelectInput>,
    ISelectByKey <DisclaimerSelectByKeyData,DisclaimerSelectByKeyInput>,
    ISelect <IDCRankGroupSelectData,IDCRankGroupSelectInput>,
    IUpdate <OfferingUpdateTotalQuantityData,OfferingUpdateTotalQuantityInput>,
    ISelect <RatingCategorySelectData,RatingCategorySelectInput>,
    ISelectByCode <GetKeyData,GetKeyInput>,
    ISelectByKey <BondReportItemSelect1346Data,BondReportItemSelect1346Input>,
    ISelectByCode <AllBondsSearchData,AllBondsSearchInput>,
    ISelectByCode <CanadianSearchData,CanadianSearchInput>,
    […]
    IInsert <BondDisclosureMessageQueueInsertData,
    BondDisclosureMessageQueueInsertInput>

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)
        return mapper.Select(input);
    return InvalidConfig<AmountCategorySelectData>();
}

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);

December 27, 2010

The Story of UltraBase: Chapter 2

Filed under: UltraBase — Grauenwolf @ 8:29 pm

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.

December 23, 2010

The Story of UltraBase: Chapter 1

Filed under: UltraBase — Grauenwolf @ 8:27 pm

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:

clip_image002

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.

Create a free website or blog at WordPress.com.