Architecture, Design and Development

Task Oriented Programming

Tim Huffam — Mon, 08 Sep 2008 12:10:06 GMT

For some time I've been wondering if there's a better way to program business logic. Years ago I used to write COBOL, then moved onto a 4GL, bla bla bla... and today I find myself well entrenched in OO with Microsoft's .Net. Development times don't seem to be much better these days - and the complexity of things seems to have mushroomed.

We went from barely-a-3GL to 4GL back to 3GL plus an explosion of things you need to consider. We started with procedural code then moved to OO and seem to have got stuck there. But somehow I think we need to revise our use of OO. Business logic is predominantly procedural code - even if written in OO; it starts, follows a process, performing stuff until finished eg Customer.UpdateCreditLimit()

OO is really good for modelling things - as per the classic OO examples of a bicycle or car. And thus they model business things quite well too - like an Invoice or a Customer.

However, I've found that the more object oriented the code gets - the less productive, maintainable and flexible it becomes. Not saying leave OO - far from it - it's brilliant. It's just that we need to learn when to say 'when'. The use of patterns has helped a huge amount - but these can also caused similar problems - when being applied where they aren't really needed - resulting in overly complex software (read: inflexible and unmaintainable and unproductive). It's a fine line - and it's not easy to get the balance.

A major break through in this area is LINQ. This has meant we have less clutter in our apps catering for ORM (brilliant). This has resulted in code very similar to the old 4GL days (essentially 4GLs were just SQL based code anyway) - where all you care/code about is the business logic - caring not a jot about how or where a Customer or Order got created - and in this age of SOA - that becomes more important (as a Customer could come from many different sources - local RDBMS, company ERP, external CRM etc). I guess you could say LINQ allows you to focus your code to be more domain specific (not saying it's a DSL).

I have been playing with workflows for donkeys of years and found that although the individual workflow systems themselves can range from very simple to incredibly complex - the individual tasks they perform need not be. This had lead me to start thinking about applying this principle to code design at a reasonably low level.... what if we developed tasks as objects. Each task has just one job (I've heard some people say this is how objects 'should' be coded anyway). It has properties that can be get/set. Keeping things dead simple, eg:

public class AdderTask
{
    public int Addend1 { get; set; }
    public int Addend2 { get; set; }
    public int Result { get; set; }
    public AdderTask(int addend1, int addend2)
    {
        Addend1 = addend1;
        Addend2 = addend2;
    }
    public AdderTask Execute()
    {
        Result = Addend1 + Addend2;
        return this;
    }
}

To run this you'd simply do this:

int result = new AdderTask(1, 2).Execute().Result;

Exposing the task's properties means you can build up get and set statements - and because the Execute method returns the task object itself you can easily use it in a single line as if it was a method on it's own - or retrieve it's property values after the Execute (these tasks would easily be adapted to work within a workflow system).

This style lends itself to expanding; rather like building blocks, you can build large workflows out of these task oriented blocks. The workflows themselves coded just like these tasks - whereby all the business logic resides within the Execute() method.

Adding LINQ to the mix takes this to the next level - allowing you to build software that is simple to develop and understand.

I've been building a sizable system using this technique and I'm finding that I'm converting code developed using standard OO practices over to this methodology as it makes code more easily reused - but most importantly: easier to read and maintain.

In summary:

All input and output parameters should be implemented as properties (getter and setter accessors).
Provide a constructor that accepts all required parameters. A default constructor (with no parameters) is optional (I've found I never need these - but if you were to use these tasks in a workflow system they may need this).
Provide an Execute() method that takes no parameters and returns the object instance eg return this;
The object should clean up after itself.

Other notes:

Originally I created a similar type of class for workflows - but I found that these ended up being no different in concept to tasks. Likewise I've found that some tasks needed to call other tasks - so I've ended up just implementing everything as tasks. On reflection this is actually quite valid - because, as I found when building large orchestrations using Biztalk, workflows become atomic tasks themselves when used within the context of a large orchestration (which may run many workflows and external tasks) - and the orchestration, from a highlevel could also be considered an atomic task.
I've found using System.Transactions.TransactionScope great for scoping transactions around many tasks when creating a macro task that runs many sub tasks.

Suggestions/comments very welcome - I'd like others to expand or comment on this.

Tim

Application Architecture, Software Development Frameworks, ORM, MVC/P and the Holy Grail - Part 1

Tim Huffam — Sun, 17 Feb 2008 02:25:01 GMT

Note this article is primarily based on Microsoft/.Net technologies, although the principle apply to any technology.

Before development of any reasonable business software project begins the following areas need to be nailed down:

Application Architecture (application structure)
ORM (Object/Relational Mapping - data source access and translation to/from business objects)
Base framework (system framework, helper classes, base classes, etc)
UI.

There are many tools available that will dictate or guide the architecture and generate ORM and base framework. Most of them do a very good job and fulfil their base requirement: to facilitate and speed up development.

Unfortunately there is no silver bullet - so the difficulty is choosing the right one. The definition of 'the right one' will vary based on the application's requirements. However there are some basic guidelines that will make this decision easier (listed in order of weight).

Policy. Does your company (or customer) have specific policy that will dictate what you use eg 'We are only a Microsoft shop' - allowing no 3rd party tools. This may also include things like 'only source compiled by us', which means you must have access to the source code of whatever products you use (this is also useful if you need to sign assemblies using your company's own key).
Security and scalability requirements. If the application has to scale well, then it should be able to be deployed using an n-tier architecture. Likewise for security purposes you should not be accessing your data source from your publicly exposed interface eg web apps or web services located in a DMZ should use another tier (an app server), located behind a firewall, to perform data source access. The caviate to this, is to have your web app/service located behind a firewall, and exposed publicly via ISA Server (which sits in the DMZ and acts as a proxy to your app).
Application requirements and developer preference.
Ease of use - ie how long it takes developers new to the project to get up to speed with using the framework. This can have significant impact on initial development and ongoing maintenance costs. Frameworks that use industry standard patterns and underlying system framework code are good for this.

Often the underlying system frameworks are very similar - as most applications require a similar set of core functionality (eg validation, security/authorisation/authentication, string manipulation, logging, etc). The Microsoft Enterprise Library provides a lot of this out the box and is a good start and some frameworks are based on this eg .netTiers.

ORM and UI are large subjects on their own - and everyone has their own oppinion of what to do/what not to do.

ORM's

Most ORM frameworks will generate code either at design time or runtime. You will have to determine which is more appropriate to your application - flexibility and performance will be considerations.

Two of the main issues around ORMS are:

Table/data model centric vs domain/business object centric, ie does the ORM generate code based on the data model or the domain model. This is becoming a more controversial topic these days as traditionally frameworks reverse engineered from the datamodel, generating a class for every table. This made the code easy to understand - but didn't always match the business/domain model. The current trend is to model your domain first then generate top-down (this is actually nothing new - it's been around a long time in some of the original OO environments).
For database data sources, is the SQL run in stored procedures or dynamic/inline SQL in your code. This may be dictated to by policy - eg most DBA's will insist on spocs - however LINQ introduces a, much debated, alternative to this.

UI's

How a UI is implemented will be greatly dictated to by functional and deployment requirements - however one must also consider the future of the app. If it's likely that the app will be around for a long time then you should do your best to split out the UI from any business logic. This is a long-known best-practice as it will give you flexibility and portability.

Knowing what type of UI's (simple web, rich internet app, winforms, commandline, etc) your app supports is a fairly trivial task. Choosing a pattern to implement it is not so easy. One of the most popular patterns for this is the Model/View/Controller (MVC) pattern. This splits out the core components of any UI. A more recent pattern is the Model/View/Presenter (MPV) pattern - this is similar to MVC, and is better for unit testing and TDD style development.

A popular approach these days is the 'convention over configuration' style framework. Spurred on by the success of the RubyOnRails framework there have been some developments in this area in the Microsoft camps - initially by the Castle Project's MonoRail project, and now Microsoft themselves have got on the band wagon with their ASP.Net MVC Framework. All these implement the MVC pattern.

A really good article on UI patterns can be found here, and a good comparison of both MVC and MVP can be found here.

I hope this brief overview has helped shine a little light on this, sometimes overwelming, subject and, if nothing else, raise more questions - which I'll endevour to dive deeper into in future posts.

Tim