IT:AD:Patterns:Objects as Messages (using ExtensionMethods)

Summary

Make no mistake about it, Extension Methods – although no more than syntatic sugar – are fundamental paradigm shifters in as much as they afford us the possibility of bridging the divide between OO design and Message design which is more appropriate in a multi-tiered secure web environment.

Object Oriented design, where a Domain's Entity's Properties are enhanced with entity specific Methods, is better suited to non-tiered architecture (desktop, mainfrain, unsecured webservers (ie, no DMZ for the UI tier).

The reason is simple: serialization goes part and parcel with tiered development. It's required at multiple stages when passing objects from the db layer to the business layer, to the ui layer, and out to a client via an application facade layer.
But we only serialize the Properties.

But whereas serializing OO entities is trivial with the framework, the concept of deserializing OO entties is fraught with issues.

Once can create a reference to an assembly contiaining the same entities – but that creates a Monolithic architecure, defeating the advantages of uncouple architectures.

Or one can deserialize an object into a secondary object that matches mostly the same properties, and may have different methods.

The later is better architecturally (un-coupled).

But if we are losing the methods in the process, what's the point of OO?

Aha. Exactly. In an era of IT:AD:Patterns:Service Pattern OO – especially when lossy – becomes suspect.

But.

Although stateless Services are often more appropriate, there are times when the Methods should be closer to the entity.

The way to provide this illusion is to Extend the objects with Methods (ie Extension Methods) at each tier, leaving the Object as simply a Property Bag.

I call it the Cross-Dresser Pattern, where the Object changes its functionality as needed (Validation in the Domain Component is different than Validation up in the UI tier).

  • It's just new fangledness…sugar….why do we need it?
    • Each language has pros/cons. Extension Methods are not just sugar. They bring value by solve architectural design issues that cannot be addressed with just the first draft of C#.
      * They're slow…
    • Where did you pull that 'fact'? Total hogwash, anyway. I actually checked. Same speed as anything else.
    • I saw a page where Microsoft doesn't recommend it…
    • Really? I guess all large corporations have different factions. Certainly dumb ones. Dumb ones that don't realize that the whole of Enterprise Library – one of their primary products – is based on Linq and uses Extension Methods extensively…