Category Archives: Code

Software Development

Why OO Business Applications Always Wind Up Splitting Methods from Data And Not Encapsulating Either

One of the main—perhaps the main—selling point of OO is Encapsulation. Which is actually two selling points. Firstly Information Hiding, that is, hiding the innards of a class so you can use it without needing to know how it works. Secondly Modularity, holding related data and methods together in one place. It’s the use of objects & classes to achieve these two effects that gives OO a large part of its flavour, distinct from procedural or functional programming.

The power this gives is the ability to model the domain naturally. This is power of OO. Given a business having customers with addresses, orders, invoices, products etc, we can model the domain – the entities and their relationships – very naturally in code by creating classes to represent them.

So as OO developers coming to line-of-business applications we expect to apply these techniques. We think about what should be private or public to each class, and we think about what responsibilities belong with classes, and what methods & data are needed to fulfil that responsibility.

The problem is, businesses don’t do modularity and information hiding. (Well they do of course, by being split up into business functions – sales, accounting, warehouse, customer services etc. Information private to one department is not usually available or even of interest to staff in another. But that’s not the level we’re interested in in a domain model).

Look again at our OO classes: customers, addresses, invoices, orderlines, products etc. These things are not encapsulated in business use at all. Firstly, there is no hidden information; when a business user goes to their information system to get information about a customer they expect just that: Information. No hiding. Secondly, information is all they expect. They do not expect the information system to model the customer’s ability to Walk() and Talk(). No methods – and so little modularity – are needed.

This is true of almost everything in a business’s domain model. From a business users point of view, it’s all just screens of information. Documents. And this – the humble document – is the heart of what we missed in our sketch of a domain model. The real thing we are modelling is not the flesh and blood Customer, or the physical Product they want to buy. What we’re really modelling in line-of-business apps is paper documents in a filing cabinet.

A piece of paper in a filing cabinet has no methods to model. It’s just a data-holder. An accurate domain model for a piece-of-paper-for-a-customer is just a list of fields or properties. You can wrap get() & set() methods round them if you like, but all you’re doing is adding boilerplate. (As an aside, a big advantage of computers over paper is much better performance in modelling relationships between those pieces of paper. A database can look up a customer’s order history much faster than a human with a set of filing cabinets).

So where are the methods in a business? They are largely in the business processes. (The phrase ‘business process’ is one that your business people use, which tells you that business processes should be part of your domain too).

To the business, a process is usually a sequence of actions done by a chain of people. In a typical business process, a piece of paper (actual or virtual) is passed around; information is updated on it, or on other pieces of paper; and very occasionally something is actually done, such as finding an item in a warehouse and putting in a box.

Which class in your domain is responsible for these actions? Probably none of them. You could create a WarehouseWorker class responsible for Pick()ing and Ship()ing the product, but you’ll quickly realise (unless your warehouse is staffed by robots for whom you are writing the control programs) that you can’t write any code that actually belongs in those methods. You can write code for UpdateStockCount(), to record the fact that stock is decremented; and you could write an UpdateCustomerOrderStatus() so that the customer services department can tell the customer how their order is getting on. Indeed, that’s probably exactly what’s being required of your system. But which class in your domain responsible for these actions?

If you think that the Customer class, or the Order class, is responsible for UpdateCustomerOrderStatus(), then you would appear to be imagining a piece of paper updating itself, which is not a normal responsibility for a piece of paper. (Either that, or you’re imagining the ghost of the customer coming on-site to keep track of their order. The real customer has no such responsibility. Their only responsibility at this point is to sit at home waiting for their package to arrive). In the world before computers it was probably the responsibility of the Stock Controller or Inventory Controller (yes, those are real job titles still held by real people) to do this book-keeping. So your domain model could/should include a StockController class with that responsibility.

Now ask yourself, what data do I need to encapsulate in the fields of a StockController class? The answer is almost certainly none whatsoever. You are not usually asked to model the real stock controllers’ working hours or height or physical strength in a line-of-business application. All you need to model is their ability to UpdateStockCount() & UpdateCustomerOrderStatus(). You need model no internal state.

This is typical of business process modelling. Business processes are nearly always stateless – all the information they need is given to them each time they are invoked. This is true for so-called ‘long-running’ processes too: the classes responsible for performing each step of the process are not responsible for holding state. Rather, they expect to have data (or ids/keys to look up the data) passed to it.

In short: ninety percent of the domain of a line-of-business application is usually correctly modelled as:

  • Documents holding data
  • Stateless public processes which receive these documents as their inputs

Because most of what you are modelling is paper documents (which do nothing, except record data) being worked on by employees (about whom you know nothing, except their ability to update the documents).

And that’s why data is not encapsulated in business applications, nor are methods and data held together in the same class.

Objections

But wait – surely we still have encapsulation and information hiding between for instance the UI layer vs data access layer vs domain model?

Yes, that’s right. The StockController exposes the fact that it can UpdateStockCount() but hides the fact (in fact, doesn’t even know itself) that this is achieved by writing to a copy of SQL Server installed on machine XYZ. A clear sign of concerns that should be separated at quite a high level is that they are semantically unrelated, that is, they speak a different language. The UI layer and the domain model know nothing of this ‘Sql Server’ of which you speak.

The point is rather that you should not be disappointed if it turns out that your domain model feels more anaemic than rich. That models the reality of typical business domains.

What about business rules & logic? They aren’t stateless business processes?

Also true. And the above line of thought need not be applied to them. (Does an abstract concept such as ‘business rule’ have state? Yes if it’s the-rule-as-applied-to-a-specific-case; no if it’s ‘The Rule’ in abstract).

Compile & Build Mono on Mac OS X

In spite of what you might still read on http://www.mono-project.com/, mono source moved to github.com/mono/mono. To build and compile on the mac however the simplest instructions are still the “One Stop Shop Build Script” at the bottom of http://www.mono-project.com/Compiling_Mono_on_OSX. They worked for me first time although I hit a couple of issues:

  1. Having a space in the path to where I built it broke the build script
  2. Fetching the mono repo from git failed several times. This may – or may not – be related to the OS X 10.9 Mavericks / Versions issue noted at http://www.git-tower.com/blog/make-git-rebase-safe-on-osx/ but I’ve had no further problems since following their instruction to
    git config --global core.trustctime false

Asp.Net MVC4 C# Razor Template for Mono on Mac and Linux

Is available on www.github.com/chrisfcarroll/AspNetTemplatesForMono/Mvc4CSharpRazorFx45Intranet. (The github download includes all the required dlls in case you don’t have NuGet working, so it’s an oversized download. If you do have NuGet working, you’ll find everything as NuGet expects).

One step to get the MVC4 template working on Mono

Download from github and open the solution in Xamarin Studio. It should almost work out-of-the-box; the one thing you have to do is either do this from the command line:

sudo mkdir /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry
sudo chmod g+rwx /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry

(replacing 3.2.5 with your mono version, which you get at the command line with mono --version);
Or, the alternative to this is to delete the reference to Microsoft.Web.Infrastructure.dll from the project and delete it from the bin directory too.
Small disclaimer: tested on Mac only. If you can offer feedback for Linux/Windows that would be great.

Footnote: How to build the Visual Studio Asp.Net MVC 4 template on Mono

For the interested who have a copy of VS2012, here’s the recipe.

  1. From Visual Studio 2012 create a new Project with the C#-Web-MVC4 Wizard and choose Intranet-Razor-No Unit Test.
  2. Try to run the resulting project on Mono on Mac.
  3. Address the problems arising in the following order
    1. System.UnauthorizedAccessException

      Access to the path “/Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry” is denied. (Where the whole path varies by O/S & 3.2.5 is your mono version).

      Resolution

      sudo mkdir /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry
      sudo chmod g+rwx /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry

      i.e. allow members of admin group to read/write the registry. Obviously you could widen privileges but this is all that’s needed for asp.net.

    2. System.TypeLoadException

      Could not load type ‘System.Data.Entity.Migrations.Sql.SqlCeMigrationSqlGenerator’ from assembly ‘EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.

      Resolution

      Remove references to Entity framework from THREE places: web.config, Project references AND delete them from the bin directory if they in there:

      • System.Data.Entity
      • System.Web.Entity
      • Entity.Framework
    3. System.TypeLoadException

      Could not load type ‘System.Net.Http.MultipartRelatedStreamProvider’ from assembly ‘System.Net.Http.Formatting …

      Resolution

      add this redirect to the web.config. You should find there are other ‘dependentAssembly’ redirects in there within the section so put it alongside them:

      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
          <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
        </dependentAssembly>
    4. And finally … System.Web.HttpException

      Unauthorized.
      Because you don’t have windows authentication available to you when running on Mac or Linux.

      Resolution

      Comment out

      <deny users="?"></deny>

      from the web.config.
      Note that you’re now unsecured. The simplest way to add security back in is to use Forms authentication. If you don’t know how to do this, the simplest start might to look at http://google.com/search?q=Forms+authentication+user+names+in+web.config

Kudos

Serving Asp.Net MVC4 pages on Mono with xsp. That is, with xsp4

I couldn’t see why the command-line xsp command didn’t work until I realised there is an not-very-well-advertised xsp4. At which point I guess the 2 in xsp2 means .Net 2 rather than, say, xsp version 2. So now I know that:

To run an Asp.Net 4 or 4.5 web application you need xsp4; whereas to run an Asp.Net 2 (or 3 or 3.5) app you need xsp2.

man xsp4 returns nothing, but the switches all seem to be the same as you’ll find with man xsp. So to run your MVC4 web app from the command line, cd to the web app directory and just run xsp4.

Asp.Net MVC 4 on Mono and Windows

Having at last got an Asp.Net Mvc 4 project template working on the Mac/Xamarin/Mono, I came to grief again when deploying it to a Windows hosted server. The problem is that whereas mono works without Microsoft.Web.Infrastructure.dll (and indeed is likely to give errors if you have it), for hosting on Windows you must re-include it.
So my deploy process now includes putting Microsoft.Web.Infrastructure.dll back in the web application bin/ directory; and now I can develop on the Mac and deploy to a Windows Server.