Summa

In every enterprise application, there exists reference data - those simple entities that live on the periphery of your data model, and are used to classify your master data. We often know these entities by other names (depending on our point of view), for instance “lookup tables”, “configuration data”, etc. - examples being “State”, “CustomerType”, or “ProductType”.

Now there are some strong reasons to model these entities in separate tables in your relational database, and there is generally not much debate here. Where things get a little tricky is when this reference data propagates up into the application tier. In my experience, developers employ a number of different strategies to solve this problem, and so in this post I’ll define some of the more popular approaches and describe the pros and cons of each. As always, I’d love to hear your thoughts, so please share. Here goes…

Continue Reading 6 comments

Planning for application modernization projects frequently stalls because decision makers are frozen in their tracks by uncertainty around the wide range of options and approaches to replacing, improving, rehab’ing or reusing a legacy system. Build versus buy; go fast versus go slow; good versus cheap; user impact; technologies to use (and not use); level of reuse of legacy “stuff”; historical data access; data quality and IT skills are just a few of the considerations that boggle architecture decisions and confound planners. This article outlines some of the metaphors and patterns that have been useful to break the gridlock.

Continue Reading Add comment

You get in to work, grab a cup of coffee, and start your day with a nice, simple, easy-to-read method that stores a value object in the database. By lunch, it has ballooned to 8 lines of code, most of which handle exceptional cases, and make sure that maintenance developers can handle them in testing and production. In this post, I will describe four approaches that I have seen for minimizing this problem and describe some pros and cons for each. The four approaches are, in no particular order:

* Aspect-Oriented Programming (AOP): define an advice class that gets executed whenever any method throws an exception. Log the exception in the advice.

* The catch-all method (i.e. highest interface/tier logging): Log no exceptions at lower levels and allow all runtime exceptions to bubble up. At the highest tier (such as a web UI, main executable, Web Service, etc.), catch all exceptions and log them.

* Self-logging exceptions: Define a base exception class that logs itself in the constructor (takes a message and possibly a Class as parameters). All exceptions in the application must extend from this base class (3rd party or library exceptions must be caught and re-thrown), but no application code should ever log an exception.

* Developer logging: As above, each developer logs exceptions as they see fit.

Continue Reading 4 comments