Mark Needham

Thoughts on Software Development

Coding: Light weight wrapper vs serialisation/deserialisation

with 5 comments


As I’ve mentioned before, we’re making use of a MarkLogic database on the project I’m working on which means that we’re getting quite big XML data structures coming into our application whenever we execute a query.

The normal way that I’ve seen for dealing with external systems would be to create an anti corruption layer where we initialise objects in our system with the required data from the external system.

In this case we’ve decided that approach doesn’t seem to make as much sense because we don’t need to do that much with the data that we get back.

We effectively map straight into a read model where the only logic is some formatting for how the data will be displayed on the page.

The read model objects look a bit like this:

class Content(root : xml.Node) {
    def numberOfResults: Int = (root \ "@count").text.toInt

They are just lightweight wrapper objects and we make use of Scala’s XML support to retrieve the various bits of content onto the page.

The advantage of doing things this way is that it means we have less code to write than we would with the serialisation/deserialisation approach although it does mean that we’re strongly coupled to the data format that our storage mechanism uses.

However, since this is one bit of the architecture which is not going to change it seems to makes sense to accept the leakage of that layer.

So far the approach seems to be working out fine but it’ll be interesting to see how well it holds up if those lightweight wrappers do end up needing to have more logic in them.

Be Sociable, Share!

Written by Mark Needham

June 26th, 2011 at 1:58 pm

Posted in Coding

Tagged with

  • If I understood correctly your model is composed of adapter objects which translate between the back-end model and the presentation model? If that’s all you guys do I’d say it’s fine. 

    The key to a good layering strategy is not to have multiple small layers but to make sure everything inside a given layer, being that layer fat or not, is up to the same abstraction level.If you also need some objects which are not just adapters, then you may find some funniness, though. In this case you can possibly still keep them in the same layer (i.e. abstraction level) but I’d probably use modules to split adapters from proper objects, assuming there is a natural split in the domain language.

     If such split doesn’t exist I see two strategies: 1st) the system is small enough, it won’t be a big deal 2nd) Use DIP, have the adapters as implementations of business concepts expressed as interfaces in the business layer and dont let those implementations leak

  • Yeh those objects are effectively adapters, that’s a better way of describing them. 

    I’m not sure how much actual domain logic is going to end up in this application. A lot of the work is massaging the data into a specific shape and it’ll probably be done by our ingestion process or by an xquery expression before it reaches the application.

    Right now we don’t have any proper objects in this system – it’s just adapters! 

    We’ve been trying to make the methods on those adapters describe the language that is used in the domain to describe what’s going on.

  • Sam Newman

    Seems fine to me too. This *Is* just data you are pulling out. Don’t fight it.

  • Lasse Westh-Nielsen

    “this is one bit of the architecture which is not going to change”

    Classic 😉

  • @a5cec89fdacafe8ed52d49a8f79a3f3a:disqus I know! 😛