Look forward to seeing you there!

NServiceBus 3 Day Course comes to Melbourne Australia is a post from: Living in the Tech Avalanche Generation

I started a series of posts on this topic recently if you are interested in a preview of the subject matter. You can register here.

Speaking at alt.NET is a post from: Living in the Tech Avalanche Generation

I have worked with lots of different types over the years and developers are no different to most, there will always be people at work who think they are simply ‘entitled’, owed a sweet ride; some think their employers owe it to them, others think their colleagues do and in society some think their government does. Lately with the whole Windows 8, Silverlight / WPF ‘will they’, ‘wont they’ deliberations in the developer community, there has been some resentful noises emanating from developers who feel left behind by Microsoft who have gone as far to express fear for their careers and encouraged others to follow suit. I find this staggering, lacking self belief, lazy and in some cases cynical attention seeking rabble rousing.

I have invested plenty in WPF but when it comes down to it, if I have to learn something new because there is simply something better?…then I welcome the education. Perhaps had I been ahead of my time I might have incited a riot when VB6 was outmoded by .NET 1.0, instead I chose to see it as an opportunity, at the time I was faced with either moving on to Java, Swing AWT , JSP and J2EE or to .NET, WinForms, ASP.Net and all the wonderment of web services and remoting (tongue firmly plated in cheek).

Personally I don’t believe Microsoft is about to abandon XAML but if they do then I will treat it as an opportunity and expect that history will show me not to be alone.

A sense of Entitlement?…stop your whining! is a post from: Living in the Tech Avalanche Generation

It would be helpful to the discussion at this point to display the UI in question and then pick it apart. I am showing only the relevant portion of the screen that was subject to the discussion, in this case the twenty four hour digital clock. Each line item in this dashboard contains a due time and indication as to the amount of days or months passed or to follow. The screen shot shows three line items where:

1. Is due in 10 days at 5:38 PM
2. Is due today at 5:26 PM
3. Is due in 10 days at 4:16 PM

Things to note: the ‘number of days indicator’ (below) and digital clock are both right aligned, placed in close proximity to each other and each element is repeated regardless of their values, establishing a unified consistent layout.




The Debate

To understate the debate better there is one feature of the underlying business logic that should be understood first; a high percentage of jobs are turned around in the same day, meaning the ‘number of days indicator’ will exhibit the value of “TODAY” at a high frequency. 

One suggestion in the discussion was that given that the large percentage of due dates would evaluated as “TODAY” then it would make sense to omit it. The logic behind this is that most jobs get done “TODAY” making it almost a default value.  Here (to the left) is what it would look like if we enacted the business logic on the layout of he user interface and looking at the result the converse arguments become clear:

1. It creates trapped whitespace.
2. It is less organised through loss of repetition.
3. It is less unified with the loss of proximity.

The other effect of removing the ‘number of days indicator’ is that users will have to be trained in the rule that the omission has a specific meaning. If most line items would show “TODAY” then its likely that the repetition of the text or trapped whitespace would make it possible to spot the exceptions, however the loss of organisation in the layout through the introduction of trapped whitespace makes it more difficult to discern, even with a ‘squint test’ where the user deliberately searches the screen for the items with an empty value in the ‘number of days indicator’.

In writing this post it also became clear that the upper case rendering of characters in the ‘number of days indicator’ needs to change with a view to making it less cluttered and achieving better contrast with the 24 hour clock.

All in all a very useful discussion where the debate continues testing the principles in place and highlights the need to retain some simple, subtle yet effective design choices that continue to be refactored through the iterations of the application.

When to ask users to use their eyes to reason by omission? is a post from: Living in the Tech Avalanche Generation

Change starts within!

Eventually the CEO comes up with a new product idea that has him so excited that your team is whipped up to fever pitch on the promise of starting a new application from scratch, the time has come to start popping the greenfield champagne corks in the cubicles on the software development floor. In the earliest of design meetings the noise about NoSQL has picked up ferociously, the senior and junior developers are all beating their chests and pushing hard for the company to agree to adopt this new paradigm for data persistence but you have anticipated your bosses reaction, knowing full well he will have some serious commercial concerns about choosing a NoSQL platform to underpin your data storage; what about the clients and all their institutional dependency on SQL, what about all their quirky integration hacking between your system and someone else’s, imagine the new plethora of support requirements for clients that have barely heard of NoSQL let alone have a administrators with the capacity to manage it…the list goes on.

As a hands on kind of guy you also see the benefits of the NoSQL choice and if you have to write as much data access code as you have routinely over the years (regardless of your fancy dancy ORM) you might just loose interest in this new shiny project. At the end of the day the boss beats you down and the same old reliable safe choices get made for data access and storage, you are left wondering what has to change so this doesn’t become the default position until such time as you retire!

When you think about how long SQL has been ensconced on its throne, the ubiquity of the SQL language and its potential for universal tooling, then question begs, how long would it take to make NoSQL a transferable skill between jobs, enough to permeates IT and seep out of those cracks and into operational non IT staff skill set?

UnQL resume fodder?

The recent news on UnQL has tongues wagging about the potential for a universal language for document databases, should the vendors decide to implement it of course. Nobody in their right mind is expecting this to happen terribly quickly and even if it does eventuate and provide us with the basis of some equally powerful universal tooling that can be found in the SQL world, there is a deep drop between there and crossing the chasm of bureaucratic red tape and all the elements of resistance to change. I wonder how long it is till we see recruiters list UnQL in job ads?

Independent Software Vendors

Storage concerns that bleed into architecture choices as a direct result of commercial concerns can do so in ways that and in-house software team or web 2.0 vendor may not typically have to consider. There is a degree of user data hacking that ISV’s need to consider upon servicing a wide range of clients who possess peculiar concerns and workflows. This can lead to any given client choosing to customise the software vendors product database. Some ISV’s encourage this behaviour and others don’t, opting for building points of extensibility. Making points of extension available is useful approach but it doesn’t eliminate client resistance when the only integration avenue open to them is constrained by their institutional dependency of SQL.

As a software developer / vendor I find myself often wanting to take advantage of a schema free database but in some instances it represents a potentially commercially damaging choice, one that simply cant be made. The exception might be ancillary tooling in a product suite, applications with small surface area as far as clients are concerned and any projects that fall outside of the scope of client SQL integration needs.

NOTE: I am fully aware that we haven’t yet discussed specialised reporting or BI tooling here in this post and that its more than possible to design an architecture where SQL products are used in conjunction with a Document Database.

Institutional Resistance to Document Databases is a post from: Living in the Tech Avalanche Generation

So what were my requirements and how did we¹ go about addressing them? I spend a considerable amount of my time building task based user interfaces in smart clients and I prefer to do it very explicitly, but lets break that somewhat fluffy abstract statement down a little with the specifics:

• Explicitly Task Based means all the way from the XAML layout to the supporting C# code
• Smart Clients commonly incorporate messaging and the use of durable queues.
• I want to keep the queries and commands very separate in my code
• I want a Pipeline for handling UI messages to the controllers (think Ruby or Smalltalk)
• I’d like an environment where developers stay out of each others way.

Now lets pivot on those one at a time (not all here in part 1 however).

Task Based

Task based user interfaces offer the opportunity to model our screens sharply to the intent of the user. Consider the example of a grid that allows users to change an employees details, such a grid might include property values such as the first name, last name all the way through to the employees position in the organisation. A ‘position’ of finance clerk might very well be organisationally subject to the concept of ‘banding’ to determine pay scale.

If we provided this grid based screen for users to change an employees position, the grid cell containing the position might be populated by a combo box containing a list of positions defined by the organisation; a user would simply have to change the selection to affect a position move by an employee. But what is actually going on here in this example?…are we really just changing the employees position, or did something else occur in HR to warrant the position change? Lets say the employee was promoted and lets even assume that HR are interested in why the employee was promote…we can see we have a problem now.

It would strike me as highly surprising if any reader hadn’t been ailed at some point with this syndrome, fumbling around in some legacy relational muck, desperately trying to find ways to reason about data in storage, where the meaning of the events in the system have been inexorably lost.

Explicitly

Being Explicit sounds odd at first blush I know, but consider the example of the employee position changing as discussed previously, certainly its an explicit requirement and event; the promoting of an employee may well require the changing of the position held, its a desirable effect of making the promotion, however there could be exceptions and that indicates even greater need to be explicit. What if I were to be promoted notionally?…let’s say a pay rise with no title bump? But still, how do I do that explicitly, sure it sounds explicit but at a code level what makes it explicit? When it comes right down to it its all about interfaces, in particular what Martin Fowler refers to as ‘role’ interfaces.

Roles

Tasks can be very neatly described in a system by defining a role interface, for example I might name the role in our example as IPromoteAnEmployee.

public interface IActInMakingPromotions: IRole {}

the Commands And Query for the Role

public interface ILoadEmployeePositions : IQuery<IActInMakingPromotions>{}

public interface IPromoteAnEmployee : ICommand<IActInMakingPromotions>{}

Executing this intent explicitly might look something like this:

Controller.Handle<IPromoteAnEmployee>();

OR

Controller.Query<ILoadEmployeePositions>();

At this point the controller knows what it needs to do, or at least a container or some reflection code should be able to locate the applicative handler that will execute the logic for this command.

Note: that there are no data arguments to this command and I haven’t yet said anything about queries, certainly many commands will require facilitating data that is supportive to executing a given command. For example, lets consider that in promoting an employee we may well be expecting access to a list of positions to which any given employee might ascend to (or in the case of demotion descend): enter Command Query Segregation (CQS).

CQRS

Some of the significant benefits of using these roles (interfaces) are that it allows you to vary many of the actors in your system concordantly and we can split the handlers for the commands and queries at a code level by leveraging the CQRS pattern. What about DDD then? Well keeping queries and commands separate is something that jives well with DDD, however I should make it clear that in the case of a smart client where messaging is predominant, many of these commands will most likely re-dispatch their intent from the UI controller to an endpoint where the business logic will be handled and in my case that’s usually an NServiceBus endpoint. In the case of queries we could have our handlers do straight up RPC to the data store or via some http API that acts as a facade to a data store.

Command

public class PromoteAnEmployeeHandler : IPromoteAnEmployee
{
    public void Execute()
    {
        var viewModel = Screen.ViewModel.etc;

        Bus.Send<IPromoteAnEmployee>(m =>
        {
           //…message properties set here using view model if required
        });

        //send a message to other views interested
        Messenger.Default.Send(new EmployeePromotionMade()
        {
            //…inter screen message properties set here
        });
    }

    public IScreen<IPromoteAnEmployee> Screen { get; set; }
    public IBus Bus { get; set; }
}

If this were a typical client server system we could also do straight up RPC with the data store if applicable however in the example above I have dispatched a message on a bus (NServiceBus) to some logical endpoint within the HR service.

Query

public class LoadEmployeePositionsHandler : ILoadEmployeePositions
{
    public void Execute()
    {
        var ctx = new EmployeeViewCache(connectionString);
        var employeePosDescriptions= from p in ctx.PositionDescriptions
                                    select new EmployeePosition()
                                    {
                                        Name = p.PositionName,
                                        Id = p.PositionId
                                    };

        var items = new ObservableCollection<EmployeePosition>();

        Screen.ViewModel.PositionDescriptions = items;
    }

    public IScreen<IPromoteAnEmployee> Screen { get; set; }
}

What’s next?

On the basis that brevity is the essence of wit and not wishing to overly tax the attention span of readers, part 2 & 3 will look at pipelines and how that becomes useful, how SOLID principles are served by such an approach, the multi threaded smart client story and why I am happy to accept lots of small chunks of code spread over many files, little islands of single responsibility as I have come to know them. Finally I will look at afferent and efferent coupling and finish up with testability.

¹ Mark Harris and I are co directors of QCAT (an ISV) and Lextrico (a consulting business)

Modelling Task based Smart Clients Explicitly–Part 1 is a post from: Living in the Tech Avalanche Generation

I am attracted naturally to people with strong opinions but the ones I admire the most are those who have “the tendency to doubt and the capacity to believe in equal measure”¹, particularly when it comes to their own beliefs. In my previous career as a studio recording engineer I was (and remain) a follower and admirer of the works of Brian Eno who considered one of his talents to be the ability to liberally contradict himself, which has some foundation in artistic license, an ability to turn on a small piece of mental real estate…agility!

Silos House Dangerous Materials

The one thing that really sticks in my craw though is silo style thinking, blinkered intellectualisation, emotional investment in ones opinions where they themselves are short of any depth of investigation, whether that enquiry is introspective, empirical or studied.

¹ From the West Wing Episode Constituency of One.

Opinions is a post from: Living in the Tech Avalanche Generation

JezebelScript roamed upon High Horse, preaching her gospel to any and all that would listen; “free yourself from the hub of central control and lay seed at the root of communication” she cried. The arbiters of the peoples forums were locked in debate, a dark cloud of quandary hovered, alas so many prophets, so many gospels, even at the seat of power there seemed to be great confusion in how to best identify the “one true way”¹.

The Princesses message was simple, her key tenet was “freedom in Ubiquity” and as her powers grew as the message took root. The Oligarchs of the day were seduced by her call and they too began to preach her message, concordantly  it appeared to be reaching its crescendo, her followers gained strength in numbers, they began flexing muscles of vindication in the hallways of the propaganda machines. And then a metamorphosis took shape…something unexpected in this rich time of spiritual and intellectual evolution, the followers of JezebelScript came to outnumber those who followed the false prophets, an ugly mob mentality which had been festering, manifested itself in an un-mandated charge to suppress the new minority. The airwaves became filled with bile, hatred and self serving pronouncements of worship to JezebelScript, they shouted her name as though it laid claim to legitimacy. Finally it seemed the oppressed were now becoming the oppressor.

Her story is ongoing, her epitaph yet to be written and who knows she just may end up capturing the hearts and minds of those who have until now ignored her dance of seduction.

¹ Billy Hollis “Living in peaceful co-existence”

JezebelScript, her followers and the downtrodden is a post from: Living in the Tech Avalanche Generation

Mark and I will also be sharing our experiences of how NServiceBus has served us as an enabler in designing and delivering successful solutions for our clients as an ISV and as consultants.

NServiceBus 1 Day Kick Start Event is a post from: Living in the Tech Avalanche Generation

A while back I posted on how it was possible to self host an NServiceBus endpoint in a custom built IronPython / WPF REPL process. Since that time NServiceBus has experienced several feature enhancements and now supports a rich hosting model of its own, the Generic Host. I wont regurgitate what has already been written about the Generic Host as its been covered in several places and if you wont to know more about it I suggest you look at these links:

The Generic Host

The Profiles

Sample

So Why an IronPython Host

In short, the ability to throw ad-hoc messages at your NServiceBus ecosystem and observe your systems behaviour (eye to eye) and some dynamic debugging! The typical debugging scenario has me sitting with four or more console windows open acting as either clients, servers and or publishers and some of those windows will be waiting for input (from me), the kind of input you typically see in a console application “Press y to send a message” (usually a fairly statically crafted and compiled one). When speaking about clients and subscribers sometimes (going into production) that just might be a windows desktop application.

In the world of dynamic languages developers have come to expect the ability to test / play with / mess with / debug their code in a Repeat Evaluate Print Loop which has some significant benefits.

Start-up

Using the NServiceBus Full Duplex sample I added a reference to my hacked version of the Generic Host and set the project to start-up the executable as per the usual approach (when you have chosen not to self host in your own executable).

After starting the Server project the console fires up as expected and is then followed by the IronPython console where the hosted Bus (instance) has been made available to the script scope context we have started in.

Next I proceed to hack out a message and send it on to the Bus. What isn’t clear below is that Message1 is actually an already dialled up instance of a RequestDataMessage as defined in the message project that is part of the Full Duplex sample that comes in the NServiceBus download.

Here is the Message Handler (in the Server project) for the RequestDataMessage (in the script above Message1 is an instance of this type.

Once the script above gets executed then the REPL reports back to us (I have hijacked the STD/IO and redirected it to the REPL’s TextWriter.

Ok, so it seems obvious enough that the Generic Host is now starting up in the context of our Python REPL and I can adhoc hand craft messages and observe the behaviour of the hosted endpoint, but there are some still some issues, one immediate and obvious one is that the REPL Host is doing two things or rather taking on two independent roles namely the Client and Server. If you run the Full Duplex sample you will note that there are two processes in the solution, a client configured AsA_Client and another configured AsA_Server; when I run the Server project using the Generic Host Shell I am freeing the console window and instead running the REPL window in its place. What this means quite literally is that in this instance, the REPL Host is allowing me to send messages to the Server Endpoint (which it too is hosting), without the Client endpoint running at all, thereby effectively spoofing some of the behaviour found in the Client process (project) without actually loading the client endpoint at all.

Alternatively I can run both projects (Client and Server) as I normally would, with the exception that they are both being hosted in the IronPython host. This (arguably) offers more fidelity with respect to the two services operating entirely within their own process which is in line with a production deployment.

What the image above demonstrates is that we now have two REPL Hosts running simultaneously, one endpoint configured AsA_Client and the other AsA_Server endpoint.

I am going to leave part 1 here for now and end with an idea that has come to mind: perhaps it would be useful to run a solution (furnished with hosted endpoints) and have all the REPL hosts start up within a container, perhaps an MDI host where all the REPL windows tile / cascade? It also occurs that perhaps such this REPL host would be useful for inspecting and returning source messages to their queues or performing functions like those found in the Grid UI or perhaps even something akin to an integrated shell where an Administrator might walk up to a machine hosting NServiceBus endpoints and issue those endpoints with administrative messages? Anyway I will meditate on it for a while and perhaps stay open for some outside input.

In the next post I will talk about some of the issues facing me currently and should be able to include a link to the working example by then. In the meantime you can find the old post here and download the REPL as it was back then.

Finally, the prototype IronPython console I built some time ago is really just that, a prototype and given that I plan to use it as a live runtime tool embedded in my commercial products (at some point in time) then its really time to take it from prototype to working draft and that means its time to get serious about styling the window beyond battleship grey.

Hacking on the NServiceBus Generic Host with IronPython–TBC. is a post from: Living in the Tech Avalanche Generation

Twitter is (again) abuzz with prognostication dressed in maven style authority; tweeters are delighting in the demise of Silverlight (largely) and to some extent WPF on the back of some Windows 8 announcements. Some of the tweets I have seen even include the suggestion by their authors that they would take delight in using the news to inform XAML Developers that their livelihoods are in imminent jeopardy. I wont even bother to address that assertion other than remark that I find it says a lot about the individuals who have nothing better to do than tweet their joy at the expense of someone else’s potential misfortune.

Developer Schadenfreude leaves me cold. is a post from: Living in the Tech Avalanche Generation

It’s been palpable the level of interest and noise being made by the .NET community around MongoDB, however MongoDB has no special language affiliation and the Survey seeks to know your language preference  (with regards to the training), so if your simply interested in imbibing on the best MongoDB training around, then fill in the Survey and spread the word.

Here is the link to register your interest.

MongoDB Training in Australia with 10Gen – be counted! is a post from: Living in the Tech Avalanche Generation

If IronRuby and IronPython eventually make it all the way to Visual Studio integration in the full sense (that is packaged as part of Visual Studio itself) that would be a mark of first class citizenry.

What about Expression Blend?

Personally I work in both Blend and Visual Studio and even though the Visual Studio designer is somewhat improved and it’s intellisense is far superior than that of Expression Blend, it still does not provide me with the same fidelity or fluency in the design experience as I get from Blend. This leaves me with a problem when it comes to building applications where IronPython is the choice language.

It would have been unrealistic (at this stage) to expect Blend to open IronPython projects created in Visual Studio and sure enough that is the not case. What might be useful is Blend having a “design XAML only mode”, enabling it to open XAML files individually, taking advantage of the design experience it has to offer. Still not ready to give up on using Blend with XAML files that were part of a Visual Studio IronPython project, I set out to find a way.

Symbolic Links

The first thing I tried out was to see if Symbolic and Hard linked files would make the difference? First up I tried a symbolic link using the MKLINK utility:

MKLINK [[/D] | [/H] | [/J]] Link Target

Before doing this I created two projects, the first one an IronPython Tools project generated in Visual Studio and the second one a C# project created in Blend.

It should be obvious from the naming which project is which. In the blend project I removed the default XAML file generated by Blend.

Next came the file linking, I used only the Link and Target command line options, creating a symbolic link using the same name as the .XAML file in my IronPython project.

MKLINK pongo.xaml d:\temp\PongoBlend\pongo.xaml

Having successfully created the soft linked symbolic file I tried to add it to the Blend project only to find that it would not open – which, to blunt I wasn’t expecting to work. I was a little more hopeful however when it came to the Hard Linked file which I setup as follows:

MKLINK \H pongo.xaml d:\temp\PongoBlend\pongo.xaml

This did in fact open correctly in Blend and worked for a brief moment, when I changed something in Blend – Visual Studio would prompt me that the file had been changed outside the editor, unfortunately my celebrations were short lived when I found that the files were not updating in both locations when one or the other was subject to an edit. After some investigation and testing it appears that once opening the file in both the IDE’s the links would somehow eventually become broken and so the symbolic linking idea was now officially a lost prospect.

Duelling Projects

Finally I decided to synchronize two separate .XAML files in each of the two different projects, so the challenge was to find the most unobtrusive way of working in both IDE’s and easily syncing the the .XAML files after edits had been made. Given that one of the IDE’s was running a dynamic language with a REPL built in, I thought it shouldn’t prove too difficult.

What I did was to add two .py source files into the project, each one with some code that would sync in one direction, either from Blend to Visual Studio and vice versa. Sure its  far from a perfect solution but it just might be a price I’m willing to pay in the short term to get the benefit of using Blend. In the long term I really do hope that as the dynamic languages gain support in Visual Studio we also get some integrated ways to work in both IDE’s.

Here’s the very same Pongo.xaml file (or copy of it to be precise) in Expression Blend, but before you get too excited, the “send to interactive console” context menu option seems to suffer some kind of inconsistent behaviour (on my machine any way), causing the File copy operation in my .py files to work on only some occasions.

Undeterred I decided to fall back to an even more disintegrated experience and opt for running the synchronizing .py files in IPY.exe itself. This is easily achieved by associating .py files to the IPY.exe in Visual Studio using the context menu’s “open with” option, which is a something existing Visual Studio users will be very familiar with.

Like I said its far from a perfect solution and to be frank it’s somewhat annoying however my frustration is another thing altogether if I’m faced with doing all my layout and design in Visual Studio – so I will live with it for the moment. Hopefully the IronPython team and or the Expression Blend Team can find a solution that flows changes through more seamlessly in the short term and the perhaps in the long term allow us to open IronPython and IronRuby projects in Blend.

By the way if your wondering about the codename of the project that drove this adventure (PONGO) – the answer is yes if you guessed that it’s something that revolves around IronPython and MongoDB and I will be blogging about that more in the coming weeks.

IronPython Tools for Visual Studio with Expression Blend is a post from: Living in the Tech Avalanche Generation

NFetchSpec Code – Entity Framework Repository, Fetching Strategies, Specifications, Code Only, Mapping, POCO and Making Roles Explicit. is a post from: Living in the Tech Avalanche Generation

The Service Layer

I want to point out that this approach in development is not restricted to a technology or architecture per`se and in discussing how it fits with a ‘Service Layer’ is equally valid for a Layered Request / Response style Architecture and asynchronous messaging systems with very well defined business components.

Let’s start with a run of the mill WCF approach – I have purposely elided the interface contract for the sake of brevity.

[OperationContract(IsOneWay=true)]
[OperationBehaviour(TranactionScopeRequired=true,
                    TransactionScopeAutoComplete=false)]
public void DiscountRunOutProducts()
{
    IList<IRunOutDiscountForProducts> products = null;

    var compParams = new Dictionary<string, string>();
    compParams.Add(_conParamName, _connectionStringOnly);

    var repo = FetchSpec
                    .Configure
                    .With(new IoC())
                    .AndBuildSession<IRunOutDiscountForProducts>(compParams)
                    .ForRepository();

    using (var scope = new TransactionScope(TransactionScopeOption.Required,
        new TransactionOptions()
        {
            IsolationLevel =
                SessionBuilder<IRunOutDiscountForProducts>.ScopeIsolation()
        }))
    {
        products = repo.Get<IRunOutDiscountForProducts>();

        foreach (var product in products)
        {
            product.DiscountProductForRunOut();
        }

        scope.Complete();
    }
}

Every expression of intent here is explicit, from the name of the service operation, all the way to the application of the ROLE to the ORM. From an ongoing maintenance perspective, when any of the given actors need to be varied through the life cycle of the software, this can be done independently. For example, we don’t have to revisit our service layers code when we profile the system and find that the fetching strategy should be eager fetching for a given scenario, instead we can build a new version of the existing Fetching Strategy and drop it in. This kind of flexibility ripples through the system, with the same said for Specifications, Message Handlers, so on and so forth. If of course you wanted to change the code to accept a Specification ‘in line’ rather than have it deployed and dynamically resolved, then you could probably have just implemented an overloaded version of the Service operation to begin with and pass in the parameters required to build those pieces at runtime. The example is a one way operation but you could easily be returning values and accepting parameters (think DTO’s) in a request / response scenario. Bear in mind these DTO’s are not being mapped and subsequently attached, they are either parameters for the ORM or return property buckets for binding or mapping to a presentation model.

For a point of difference, let’s take a look at how this might work if our Service Layer was implemented on top of the popular Open Source Framework NServiceBus.

public class DiscountRunOutProductsMessage: IMessage
{
    public string DiscountedRegion{ get; set; }
    public decimal UnitPrice{ get; set; }
}

public class DiscountRunOutProducts :
             IMessageHandler<DiscountRunOutProductsMessage>
{
    public void Handle(DiscountRunOutProductsMessage message)
    {
        IList<IRunOutDiscountForProducts> products = null;

        var compParams = new Dictionary<string, string>();
        compParams.Add(_conParamName, _connectionStringOnly);

        var repo = FetchSpec.Configure
                            .With(new IoC())
                            .AndBuildSession<IRunOutDiscountForProducts>
                                (compParams)
                            .ForRepository();

        using (var scope = new TransactionScope(TransactionScopeOption.Required,
            new TransactionOptions()
            {
                IsolationLevel =
                    SessionBuilder<IRunOutDiscountForProducts>.ScopeIsolation()
            }))
        {
            var spec = new Specification<IRunOutDiscountForProducts>
                            (p => p.UnitPrice < message.UnitPrice &&
                             p.Supplier.Region = message.DiscountedRegion);

            products = repo.Get<IRunOutDiscountForProducts>(spec);

            foreach (var product in products)
            {
                product.DiscountProductForRunOut();
            }

            scope.Complete();
        }
    }
}

Something worth pointing out in our NServiceBus example is that it too is quite explicit. The message handler, handles messages expressly for the purpose of discounting products to be ‘run out’, exemplifying how the pattern is becoming more entrenched in our style of working. Once again, if we don’t like anything about the way the handler is doing it’s work, we can throw it away in preference for a new implementation.

Not to be left out

Steve left a comment and asked me not to forgo examples that dealt with inserting and updating data, Steve also wanted to know about how I go about dealing with the Unit of Work and the ‘per session’ vs. ‘conversation’ and the differences that spring up and also when working with WCF and dealing with optimistic concurrency. Fortunately this part in the series takes aim squarely at how to go about using Entity Framework in concert with Roles from the Service Layer and we tackle those questions by necessity.

Listing 1.0 – Inserts

public void add_a_product()
{
    var compParams = new Dictionary<string, string>();
    compParams.Add(_conParamName, _connectionStringOnly);

    var repo = FetchSpec.Configure
                        .With(new StubIoc() {
                            ScannedAssemblyPath = _scannedAssemblyPath })
                        .AndBuildSession<ICustomerToAddOrder>(compParams)
                        .ForRepository();

    var spec =
        new Specification<ICustomerToAddOrder>(c => c.CustomerID == “ALFKI”);
    var config = new IQueryConfigurable[] { spec };

    using (var scope = new TransactionScope(TransactionScopeOption.Required,
        new TransactionOptions()
        {
                IsolationLevel =
                    SessionBuilder<ICustomerToAddOrder>.ScopeIsolation()
        }))
    {
        dynamic customer = repo.Get<ICustomerToAddOrder>(config).First();

        var order = repo.IocContainer
                        .ConvertFromRoleToImpl<IOrderToAddToCustomer>();
        order.CustomerID = customer.CustomerID;
        order.Customer = customer;

        customer.AddOrder(order);

        repo.Save();

        scope.Complete();
    }
}

Not entirely in the spirit of things

Notice the use of the dynamic keyword above (suggested by Mark) Let me explain. Due the Entity Frameworks hard and fast rule of only allowing EntityConfiguration<T> to specify a concrete class as it’s generic argument, the flow through effects have rippled out, with the customer variable and the order variable. The problem is that the IoC container can’t know ahead of time what the implementation type for the interface might be and order.Customer property is forced to use a concrete type (not interface) to satisfy the Entity Framework for mapping purposes enforced by EntityConfiguration<T>. After speaking to David DeWinter (a Tester on the EF Team who responded to a tweet I made), he suggested that it was likely implemented this way to satisfy ObjectSet<T> which also constrains to a concrete implementation (makes sense).

Ultimately the dynamic keyword will get us over the line with respect to this one final hurdle, however my gut says that this work around isn’t entirely in the spirit of NFetchSpec and smacks a little of my old enemy the VARIANT, but I’m prepared to make this one allowance to get me working in a way that suits my needs. I can still read the code somewhat clearly because even when I’m using dynamic for assignment, I can reason about the type based on the interface specified to the repository and the IoC container. I would love to think that this is something that the Entity Framework team might address but I guess I will just have to wait and see.

Under the covers

What code did I need to write to support this ‘adding a product to a customer’ scenario? First up I needed the role itself, then the entities, the mapping classes, the mapping role class and I also needed to write an implementation for IProvideIsolationLevelFor. The Specification I chose to write inline because the parameter value would be provided at run time. Here is the all of it:

The Roles

public interface ICustomerToAddOrder
{
    void AddOrder(IOrderToAddToCustomer order);
    string CustomerID { get; set; }
    ICollection<OrderToAddToCustomer> Orders { get; set; }
}

public interface IOrderToAddToCustomer
{
    string CustomerID { get; set; }
    CustomerToAddOrder Customer { get; set; }
    int OrderID { get; set; }
}

The Entities

public class CustomerToAddOrder : IEntity, ICustomerToAddOrder
{
    public string CustomerID { get; set; }
    public ICollection<OrderToAddToCustomer> Orders { get; set; }

    public void AddOrder(IOrderToAddToCustomer order)
    {
        if (Orders == null)
            Orders = new List<OrderToAddToCustomer>();

        Orders.Add(order as OrderToAddToCustomer);
    }
}

public class OrderToAddToCustomer : IEntity, IOrderToAddToCustomer
{
    public string CustomerID
    {
        get;
        set;
    }

    public CustomerToAddOrder Customer
    {
        get;
        set;
    }

    public int OrderID
    {
        get;
        set;
    }
}

The Mapping Classes

public class CustomerToAddOrderMapping : Mapping<CustomerToAddOrder>
{
    public CustomerToAddOrderMapping(string objectSetName)
        : base(objectSetName)
    {
        Property(c => c.CustomerID).HasMaxLength(5).IsRequired();
        HasKey(c => c.CustomerID);
        Relationship(c => c.Orders).IsOptional();
    }
}

public class OrderToAddToCustomerMapping : Mapping<OrderToAddToCustomer>
{
    public OrderToAddToCustomerMapping(string objectSetName)
        : base(objectSetName)
    {
        Property(o => o.OrderID).IsIdentity();
        Property(o => o.CustomerID).HasMaxLength(5).IsRequired();
        HasKey(o => o.OrderID);
        Relationship(o => o.Customer)
            .FromProperty(c => c.Orders)
            .HasConstraint((o, c) => o.CustomerID == c.CustomerID);
    }
}

The Mapping Role

public class CustomerToAddOrderMappingRole :
        IMappingRole<ICustomerToAddOrder>
{
    private IMapping[] _mappings;

    public CustomerToAddOrderMappingRole()
    {
        _mappings = new IMapping[]
        {
            new CustomerToAddOrderMapping(“Customers”),
            new OrderToAddToCustomerMapping(“Orders”)
        };
    }

    public IMapping[] Mappings
    {
        get { return _mappings; }
    }
}

The Transaction Isolation Class

public class AddOrderToCustomerIsolation :
        IProvideIsolationLevelFor<ICustomerToAddOrder>
{
    public IsolationLevel GetScopeIsolationForRole
    {
        get { return IsolationLevel.ReadCommitted; }
    }
}

Piggy in the middle

The issue of managing a short or extended session with an ObjectContext is something that I think a lot of people struggle with. Personally I have never had such an issue because they way I have always worked always involved fetching the most current version of the data I required to have my domain model work against it. This way of working has stayed with me through time immemorial, even in my dark old days of using an anaemic domain model.  To be clear I do not pass DTO’s around and reattach them to the ObjectContext, rather refreshing the data and letting the domain model’s business logic take care of the rest.

In Conclusion

My initial planning for the series was that would be take up four posts and therefore it is expected that this may be the last in the series. However, given that Entity Framework 4.0 is still not at RTM and Code Only is still in CTP then it’s possible I may revisit it with a further post sometime in the future.

Helping Entity Framework v4.0 play it’s <ROLE> – Part 4.0 is a post from: Living in the Tech Avalanche Generation

Does this look like you? Are you surrounded by like minded individuals, sharing a community experience at work with your fellow geeks? Perhaps you have even gone further than that and made a lasting friend or two out of your fellow developers. That certainly describes  the kind of environment that I flourish in and in my more senior years, have worked hard to foster. It’s my experience that software developed in this environment is more cohesive and easier to maintain over the long haul. With he right personality types, social activity at work for geeks  often means talking shop and this leads to a win – win situation for everyone. More ideas begat better ideas, common work patterns begin to evolve; other than that it’s just plain more enjoyable.

However I have struck the odd workplace that is the antithesis of what I have just described. Personality bereft work silos, with dead silence abounding throughout the organisation, lack of willingness to work together, fostering a cycle of suspicion and loss of preparedness to work as a team. I have seen enough of this type of work place to know that I can never work in one again.

Of course it’s possible that I have just described your workplace and perhaps even worse than that, it’s the way it is because you designed it to be that way? What kind of work environment do you have? Do the developers at your office communicate with one another vibrantly, rich in tone and timbre, taking coffee breaks together, occasionally going out for lunch and generally taking any office bound social opportunity to debate and discuss geeky things? Do you have a mate at work?

I would really be interested to hear the arguments (if there are any) that make a case for this almost Brechtian bleakness and minimalism in surroundings.

Are we not men - we are Devo? is a post from: Living in the Tech Avalanche Generation

ADSD Course with Udi Dahan in Sydney Australia for November 2010 is a post from: Living in the Tech Avalanche Generation

Figure 1.0

Code from Figure 1.0

public void resolves_everything_from_container()
{
    IList<IRunOutDiscountForProducts> products = null;

    var compParams = new Dictionary<string, string>();
    compParams.Add(_conParamName, _connectionStringOnly);

    var repo = FetchSpec.Configure
                            .With(new IoC())
                            .AndBuildSession<IRunOutDiscountForProducts>
                                (compParams)
                            .ForRepository();

    using (var scope = new TransactionScope(TransactionScopeOption.Required,
        new TransactionOptions()
        {
            IsolationLevel =
                SessionBuilder<IRunOutDiscountForProducts>.ScopeIsolation()
        }))
    {
        products = repo.Get<IRunOutDiscountForProducts>();
        foreach (var product in products)
        {
            product.DiscountProductForRunOut();
        }

        scope.Complete();
    }
}

Figure 1.0 demonstrates how all the moving parts in the developer experience are put to use when using the NFetchSpec libraries to query and make changes to a persisted Domain Model. Let’s now examine in detail all the steps that make up the entire developer experience of composing all the discrete pieces needed in addressing the role of IRunOutDiscountForProducts (in our fictitious system).

The Development Scenario

The first outlined section in figure 1.0 demonstrates the building of an appropriate ObjectContext for the Repository that is instantiated by the fluent interface. From the developer experience perspective, nothing special needs to be done outside of specifying the role to the fluent interface in this manner.

The second outlined section in figure 1.0 highlights how the role is leveraged to dynamically have NFetchSpec chose the ‘right’ isolation level. Being explicit in this way we can achieve a high degree of separation of concerns with respect to transaction isolation and thus exercise our control over the concurrency and throughput in the database on a role by role basis. In the example, we are discounting products earmarked for a run out sale, consequently changing their unit price, therefore we might like to choose a higher isolation level for that particular operation, depending on the volatility of the data that your dealing with and the normalization or lack thereof in your database schema. For the developer this means creating a concrete implementation of the interface IProvideIsolationLevelFor<T>, to support this automagic behaviour.

public interface IProvideIsolationLevelFor<TRole>
{
    IsolationLevel GetScopeIsolationForRole { get;}
}

public class RunoutDiscountIsolation :
             IProvideIsolationLevelFor<IRunOutDiscountForProducts>
{
    public IsolationLevel GetScopeIsolationForRole
    {
        get { return IsolationLevel.ReadCommitted; }
    }
}

That’s it as far as getting your transaction set for the right Isolation Level within the scope of work for a given role. If we decide at some point that this Isolation Level is not the best fit, we can replace it with a new implementation.

The Third outlined section in figure 1.0 highlights the use of the Repository to retrieve the Entities that we are interested in. This is where the NFetchSpec machinery goes to work to resolve all the purpose built artefacts that have been implemented for the given role, such as any applicative Fetching Strategy, Specification, Entity and Mapping.

The Loaded Fetching Strategy

public class ProductRunOutFetchingStrategy :
             FetchingStrategy<IRunOutDiscountForProducts>
{
    public ProductRunOutFetchingStrategy()
        : base(false)
    {
        var production_intentions =
            EagerFetchingIntention
            .CreateInstance<IRunOutDiscountForProducts,
                            ISupplier>(p => p.Supplier);

        this.AddIntentions(new IEagerFetchingIntention[]
        {
            production_intentions
        });
    }
}

The intent of the developer in building this Fetching Strategy is to load Products eagerly with their reference Supplier.

The Loaded Specification

public class RunOutProductDiscountSpecification :
             Specification<IRunOutDiscountForProducts>
{
    public RunOutProductDiscountSpecification()
        : base(p => p.UnitPrice > 5M) { }
}

The Specification is really quite simple and self evident – setting up the applicative Expression that will ultimately be translated into a ‘where’ predicate.

The Loaded Mapping

First up we need to map our Entities and that requires a Mapping<T>.

public class ProductMapping : Mapping<Product>
{
    public ProductMapping(string objectSetName) : base(objectSetName)
    {
        Property(p => p.ProductID).IsIdentity();
        Property(p => p.ProductName).HasMaxLength(50).IsRequired();
        Property(p => p.UnitPrice).Precision = 19;
        Property(p => p.UnitPrice).Scale = 4;
        Relationship(p => p.Supplier).IsOptional();
        Relationship(p => p.Supplier).IsOptional().FromProperty(s => s.Products);
    }
}

And because our example has a reference Entity in the root we require the following Supplier Entity Mapping also.

public class SupplierMapping : Mapping<Supplier>
{
    public SupplierMapping(string objectSetName)
        : base(objectSetName)
    {
        Property(s =>  s.SupplierID).IsIdentity();
        Property(s => s.CompanyName).HasMaxLength(40).IsRequired();
        Property(s => s.Region).HasMaxLength(15);
        Relationship(s => s.Products).IsOptional().FromProperty(p => p.Supplier);
    }
}

The last requirement of the developer with respect to mapping is to create a MappingRole<T>, the purpose of which is to indicate to the infrastructure which mappings are applicable to the Role.

public class RunOutDiscountMappingRole :
             IMappingRole<IRunOutDiscountForProducts>
{
    private IMapping[] _mappings;

    public RunOutDiscountMappingRole()
    {
        _mappings = new IMapping[]
                    {
                        new ProductMapping("Products"),
                        new SupplierMapping("Suppliers")
                    };
    }

    public IMapping[] Mappings
    {
        get { return _mappings; }
    }
}

The fourth and final outlined section in figure 1.0 is really the essence of what is going on here, it is entirely the reason this code is being invoked – it is the purpose (discounting products) of the system for this role. When developing in this way we need to specify the behaviour of the Role through the stable abstraction of it’s interface, and implement that behaviour in a concrete Entity.

public interface IRunOutDiscountForProducts : IProductData
{
    void DiscountProductForRunOut();
}

The Bang and Crash

So with all that done, we need to deploy our “Role inspired” artefacts to the executing processes assemblies folder and when it’s all said and done the code from Figure 1.0 executes, enlisting the service of NFetchSpec in applying the combined intent and customised behaviours described in all of the deployed pieces.

From the database perspective, SQL Profiler tells us that our intent for this ROLE has been met and the system has behaved precisely as expected.

SELECT
    [Extent1].[ProductID] AS [ProductID],
    [Extent1].[ProductName] AS [ProductName],
    [Extent1].[UnitPrice] AS [UnitPrice],
    [Extent2].[CompanyName] AS [CompanyName],
    [Extent2].[Region] AS [Region],
    [Extent2].[SupplierID] AS [SupplierID]
FROM
    [dbo].[Products] AS [Extent1]
LEFT OUTER JOIN
    [dbo].[Suppliers] AS [Extent2]
ON
    [Extent1].[SupplierID] = [Extent2].[SupplierID]
WHERE
    [Extent1].[UnitPrice] > cast(5 as decimal(18))

We can see that Fetching Strategy and Specification have been successful in shaping the TSQL sent to the server to retrieve the data. Below we can also see the effect of applying the business rules through our Domain Model.

exec sp_executesql N‘update [dbo].[Products]
set [UnitPrice] = @0
where ([ProductID] = @1)
‘,N‘@0 decimal(19,4),@1 int’,@0=3.2960,@1=1

Just one more thing

Part 4.0 will be the final part in the series and will focus on how this approach blends into a service layer in a Service Oriented Architecture and also make the code for NFetchSpec available for download.

Helping Entity Framework v4.0 play it’s <ROLE> – Part 3.0 is a post from: Living in the Tech Avalanche Generation

We are also in the throws of putting together the web site for the event which will be announce shortly.

Doing .NET Days March 6th Fully Booked. is a post from: Living in the Tech Avalanche Generation

I’m going to start this post at the end and then rewind all the way to beginning and step through how we got here. Here is some code that will return a list of products and in so doing, will dynamically determine the correct Entity type to return (a Product), will eagerly fetch their reference supplier and will apply a ‘where’ predicate to the LINQ To Entities query. All this will happen out of clear view as a result of being explicit and specifying a role / interface to the ORM when we ask it do something.

public void Some_Method_In_My_Service_Layer
{
    var products = Repository.Get<IRunOutDiscountForProducts>();
}

Now let’s briefly forget we saw this code and go back to the start.

Lets start by imagining some simple data access code that’s enormously compact and equally deceptive in it’s apparent simplicity. For a scenario, let’s propose that we want to get all the products in our system that are eligible for applying a run out discount. The business logic in achieving this function, specifies that a Products Unit Price Price  be greater 20.50 dollars and is purchased from suppliers in a given enumerable list of regions. For the sake of the example we will also say that this would require a Product entity and Supplier Entity in the following relationship.

So given our the scenario we would be required to map the Entities appropriately, choose an appropriate method of loading (lazy or eager) and apply a suitable predicate to the SQL query. Let’s now imagine that by specifying a role (in this case the interface IRunOutDiscountForProducts), that we have provided the infrastructure code enough information to query the database for products and do so in a way that meets the proposed scenario requirements enumerated above.

var conParams = new Dictionary<string, string>();
conParams .Add(_conParamName, _connectionStringOnly);

var repository = FetchSpec.Configure
                    .With(new StubIoc()
                        { ScannedAssemblyPath = _scannedAssemblyPath })
                    .AndBuildSession<IRunOutDiscountForProducts>(conParams)
                    .ForRepository();

var products = repository.Get<IRunOutDiscountForProducts>();

The line of code that interests us most at this point is the last one. By applying the role of IRunOutDiscountForProducts to the GET<T> function, we are able to indicate to the infrastructure that our intent is to retrieve a list of Products for the express reason to apply a ‘run out’ discount to them. The next line of code you might expect to see would logically be something like:

products = repo.Get<IRunOutDiscountForProducts>();
foreach (var product in products)
{
    product.DiscountProductForRunOut();
}

repo.Save();

What figure 1.0 shows is that we would like our Repository to be smart enough to know exactly what and how to fetch based on the role (the generic parameterized interface).

Figure 1.0

I promise we will get to the end soon enough but bear with me for a minute or two. One thing about being explicit with roles, it makes understanding code all the more simple. The less ambiguity the less likely someone misunderstands intent. In the realm of software development the humble interface (not the UI kind) has carried the torch ably in helping us declare our intent more explicitly, make our code better understood and free of concrete dependencies / coupling. With reverence and honour for my past (COM programming veteran status), I apologise in advance for the ubiquitous IDog example but it makes a point.

public class Poodle : IDog
{
    //….etc
}

Explicitly a Poodle must now conform polymorphically et al to the contract specified by IDog – real 101 stuff no doubt. What about a marker interface? True enough, a very useful construct, bereft of polymorphic intent and largely a utility to express membership to a conceptual entity group of some kind, often put to use in frameworks to support dynamism of some description. Let’s use an NServiceBus IMessage as an example:

public interface IMessage {}

public class OrderCancelledMessage : IMessage
{
    //….etc
}

Without going too deep into this at a code level, suffice to say that the NServiceBus infrastructure will behave in certain ways when it comes across types that implement the IMessage interface, in other words the framework is directing us to ‘mark’ a given class (or interface) as being recognizable as a ‘Message’, making it identifiable to the frameworks internal workings.

The virtues of programming by interface are now well documented and for .NET developers the advent and popularity of generics has encouraged our creativity in placing stable abstractions  around things to make code more explicit. For example, a while back I wrote in the abstract on the use of interfaces to define roles; roles describe the polymorphic nature of a business domain command and arguably event. This series of posts is an extension of those made in the past, the focus however now moves to a proof of concept for the up coming Entity Framework 4.0.

What is a Role?

Roles identify or describe commands / behaviours in the domain, an level of intent that can be be nicely defined by an interface.

public interface IRunOutDiscountForProducts : IProductData
{
    void DiscountProductForRunOut();
}

We can use these roles (interfaces) to indicate to our infrastructure (an ORM in this case) what our intent is and have the infrastructure behave appropriately based on configuration and / or convention.

Since we started with an example that focused around products, lets continue with that subject for a moment. It may be that my system needs to fetch Products for a variety of reasons and not always with the same intent. We shouldn’t be asking for a generic list of Products, considering that we are interested in them with a very specific context in mind and its the context determines the behaviour and describes the a role.

Once our system becomes explicit in this way through the use of roles in our domain, we can do some interesting things. We can instruct the ORM how to load the entity graph by implementing Fetching Strategies, dynamically resolve the most appropriate Entity Mapping to use and which predicate to apply to the query for the purpose of business logic filtering. Not only does the the role provide a stable abstraction, it insulates other parts of the architecture, perhaps a service layer or controller, from changes, allowing the actors to vary independently.

The Roles Quadrant:

Whilst working on this proof of concept in my attempts at cajoling the Entity Framework to work in this fashion, it became evident that there were four main pieces of the puzzle, Fetching Strategies, Specifications, Mapping, and Repositories. One thing that I haven’t mentioned yet, is the effect on concurrency, scale and throughput that this approach can have. Through the use of roles we can plug into the architecture yet again and explicitly pick an isolation level for the operation at hand.

using (var scope = new TransactionScope(TransactionScopeOption.Required,
    new TransactionOptions()
    {
        IsolationLevel =
            SessionBuilder<IRunOutDiscountForProducts>.ScopeIsolation()
    }))
{
    //…..do some stuff here like load data 
    //…..change data by calling into your domain model
    //…..and finally save the changes

    scope.Complete();
}

Notice that in constructing the Transaction scope we use the SessionBuilder and ask it to supply an Isolation Level for the role specified. Of course their is some IOC magic involved here but essentially the only thing required to make work is the following interface. Here is an example implementation.

public interface IProvideIsolationLevelFor<TRole>
{
    IsolationLevel GetScopeIsolationForRole { get;}
}

///Implementation

public class RunoutDiscountIsolation :
    IProvideIsolationLevelFor<IRunOutDiscountForProducts>
{
    public IsolationLevel GetScopeIsolationForRole
    {
        get { return IsolationLevel.ReadCommitted; }
    }
}

Loaded Up

_container.Register(AllTypes
    .Of(typeof(IFetchingStrategy<>))
    .FromAssembly(assembly)
    .Configure(c => c.LifeStyle.Singleton).WithService.FirstInterface());

_container.Register(AllTypes
    .Of(typeof(ISpecification<>))
    .FromAssembly(assembly)
    .Configure(c => c.LifeStyle.Singleton).WithService.FirstInterface());

_container.Register(AllTypes
    .Of(typeof(IMappingRole<>))
    .FromAssembly(assembly)
    .Configure(c => c.LifeStyle.Singleton).WithService.FirstInterface());

_container.Register(AllTypes
    .Of(typeof(IProvideIsolationLevelFor<>))
    .FromAssembly(assembly)
    .Configure(c => c.LifeStyle.Singleton).WithService.FirstInterface());

_container.Register(AllTypes
    .Of(typeof(IEntity))
    .FromAssembly(assembly));

Quadrant Position 1.0 – Fetching Strategies

Fetching strategies encapsulate our expression of requirement with respect to Eager and Lazy Loading. This feature is useful, when one considers that the Entity Framework (and most ORM’s for that matter) do not provide these capabilities with a consistent API experience, nor allow for an out of box experience friendly to a configurable or convention based approach to specifying loading characteristics for a given expression of intent. Wouldn’t it be nice if we could ask the ORM to fetch an Entity using a role, one specific to a command that exists within a given business capability? This functionality does exist with NHibernate but not currently with either version of Entity Framework, but the good news is that it is possible. There are a couple of ways of doing this and I have blogged about it more than once. At this point of the discussion it would be useful to show some code and how to configure a Fetching Strategy. First the interface:

public interface IFetchingStrategy<TRole> : IQueryConfigurable
{
    IEnumerable<IEagerFetchingIntention> Intentions { get; }
    IEnumerable<string> Includes { get; }
    void AddIntentions(IEagerFetchingIntention[] intentions);
    bool ShouldLazyLoad { get; }
    bool HasInstructions { get; }
}

Next let’s look at an implementation (we will skip the base class for now).

public class CustomerPreferedFetchingStratey :
             FetchingStrategy<IMakeCustomerPrefered>
{
    public CustomerPreferedFetchingStratey()
        : base(false) {

            var orders_intention =
                EagerFetchingIntention
                .CreateInstance<IMakeCustomerPrefered,
                                ICollection<IOrder>>(c => c.Orders);
            var orderlines_intention =
                EagerFetchingIntention
                .CreateInstance<IOrder,
                                ICollection<IOrderLine>>(o => o.OrderLines);

            this.AddIntentions(new IEagerFetchingIntention[]
            {
                orders_intention,
                orders_intention.And(orderlines_intention)
            });
    }
}

Quadrant Position 2.0 – Specification

The Specification pattern evolved around the problem of testing that the state condition of an object is met according to a given specification. This pattern has taken on some new potential with the help of LINQ. Using LINQ Expressions it’s possible to massage this pattern into something of a predicate store and when we think about developing with roles it becomes potentially more powerful again. Here is a quick look at a Specification and some usage:

var spec = new Specification<IRunOutDiscountForProducts>
              (p => p.UnitPrice < 20M && p.Supplier.Region == “London”);

Pretty simple, the constructor takes the Expression to initialise the boolean test for the specified state. The classical purpose of the pattern is to provide a single function, commonly named “IsSatisfied” to carry out the test against a given object to see if it’s state indeed meets that that has been specified.

var productToTest = new Product(){Supplier = new Supplier()};
var satisfied = spec.IsSatisfiedBy(productToTest);

This will code will obviously fail the specification test and IsSatisfiedBy() will return false. Whilst very useful in and of itself, the LINQ Expression enabled version / implementation of this pattern has some features that can be harnessed to apply a level of dynamism to the resolution of query predicates. Let’s have a closer look:

public interface ISpecification<T> : IQueryConfigurable
{
    Expression<Func<T, bool>> EvalPredicate { get; }
    Func<T, bool> EvalFunc { get; }
    bool IsSatisfiedBy(T entity);
}

The interface details the contract to provide both the Expression and Func that will provide the computation required to discern whether a specification has been satisfied. Further to that, these new properties give us opportunities to plug predicates or lambdas into the machinery as well. Looking a little deeper under the covers of the proof of concept code we will find this in operation:

return _ctx
       .CreateObjectSet<TRole>()
       .Where(predicate.EvalPredicate)
       .ToList();

Through operator overloading, Specifications can also be combined for OR and AND conditions:

Specification<Customer> german_customer_spec =
    new Specification<Customer>(c => c.Country == “Germany”);

Specification<Customer> us_customer_spec =
    new Specification<Customer>(c => c.Country == “Usa”);

var comb_country_spec = (german_customer_spec | us_customer_spec);

In the case where query predicates help to form a semi static business rule at the query level through filtering, it becomes a reasonably trivial task to deploy a new version or entirely new Specification for any given role, simply by deploying the library.

Quadrant Position 3.0 – Mapping

Now to the latest part of the puzzle to be rolled into the Proof of concept, mapping. Entity Framework 4.0 (sometime after initial release) will be augmented by code only mapping (hallelujah). When one looks at the (current CTP) API for this functionality it becomes immediately evident that this too is something that can be very easily made deterministic by adding a layer of indirection to accommodate this role based approach. The out of the box mapping in EF 4.0 makes working in this manner quite simple given the possibilities provided by the EntityConfiguration<T> class. Here is a simple example:

public class CustomerMapping : EntityConfiguration<ICustomer>
{
    public CustomerMapping()
    {
        Property(c => c.CustomerId).IsIdentity();
        Property(c => c.FirstName).HasMaxLength(50).IsRequired();
        Property(c => c.LastName).HasMaxLength(50).IsRequired();
        Relationship(c => c.Orders).IsOptional();
        Relationship(c => c.Orders).FromProperty(o => o.Customer);
    }
}

What’s required is to take this out of the box solution and add a layer of indirection requiring only a few new actors, an IMapping, an IMappingRole<T>  and a Mapping<T>.

public interface IMapping
{
    Type EntityType { get; }
    string ObjectSetName { get; }
    StructuralTypeConfiguration Configuration { get; }
}

public interface IMappingRole<TRole>
{
    IMapping[] Mappings { get; }
}

public abstract class Mapping<TEntity> :
                      EntityConfiguration<TEntity>, IMapping
{
    private string _objectSetName;

    public Type EntityType
    {
        get { return typeof(TEntity); }
    }

    public string ObjectSetName
    {
        get { return _objectSetName; }
    }

    public Mapping(string objectSetName)
    {
        _objectSetName = objectSetName;
    }

    public StructuralTypeConfiguration Configuration
    {
        get { return (StructuralTypeConfiguration)this; }
    }
}

The aggregation of IMapping’s in the Mapping Role will accommodate mapping an aggregate root with reference and collection entities. Here’s a more complete look that includes some implementing Mapping classes.

Below is an example Mapping class, notice that we still need to use the actual Entity Type and not an interface. This is due to EntityConfiguration<T> lacking in support for interfaces (as of today, perhaps that will change or already has with RC 1).

public class ProductMapping : Mapping<Product>
{
    public ProductMapping(string objectSetName) : base(objectSetName)
    {
        Property(p => p.ProductID).IsIdentity();
        Property(p => p.ProductName).HasMaxLength(50).IsRequired();
        Property(p => p.UnitPrice).Precision = 19;
        Property(p => p.UnitPrice).Scale = 4;
        Relationship(p => p.Supplier).IsOptional();
        Relationship(p => p.Supplier).IsOptional().FromProperty(s => s.Products);
    }
}

Quadrant Position 4.0 – The Repository

The final square on the grid is the Repository. The repository offers nothing more than five overrides of the one method, Get<T>. The five versions of the method are to cover the variable requirements that might crop up when consumers wish to provide Fetching Strategies, Specifications and Entities (concrete ones) inline and directly to the infrastructure. Fetching Strategies are probably the least likely candidate for this requirement but it may come in useful, Specifications on the other hand will from time to time no doubt be populated dynamically from user input, served as part of a request or message and subsequently used as a filter parameter. Let’s have a brief look at the Interface:

public interface IRepository : IUnitOfWork
{
    IList<TRole> Get<TRole>();
    IList<TRole> Get<TRole>(IQueryConfigurable[] configurables);
    IList<TRole> Get<TRole>(ISpecification<TRole> predicateWhere)
                            where TRole : class;
    IList<TRole> Get<TRole>(IFetchingStrategy<TRole> strategy)
                            where TRole : class;
    IList<TRole> Get<TRole>(ISpecification<TRole> predicateWhere,
                            IFetchingStrategy<TRole> strategy)
                            where TRole : class;
    IoC IocContainer { set; }
    ObjectContext Session { set; }
}

The first two versions of Get<T> will resolve as much as they can from the container, a Fetching Strategy, a Specification, the Mapping and will use the closest adjacent Entity type, all based on the identity of the generic parameter – that is, the ROLE. The last three versions of the Get<T> function is provided to work with the Entity Framework in a more familiar mode where and EDMX file can be specified, the concrete Entity Type itself is provided as the role parameter, we can also push through Fetching Strategies and Specifications ‘in-line’ in these scenarios. Probably not my preferred method but it’s available.

Configuration

I decided at the death to implement a fluent configuration to prime the infrastructure and create a Repository. The fluent interface is designed with the view to keeping things compact and easy to setup.

Resolve it all

public void resolves_everything_from_container()
{
    var compParams = new Dictionary<string, string>();
    compParams.Add(_conParamName, _connectionStringOnly);

    var repo = FetchSpec.Configure
                        .With(new StubIoc()
                            { ScannedAssemblyPath = _scannedAssemblyPath })
                        .AndBuildSession<IRunOutDiscountForProducts>(compParams)
                        .ForRepository();

    var products = repo.Get<IRunOutDiscountForProducts>();
}

In this example above, we are using a stub for IoC, and hard wiring the scanned assembly path to find all the implementing Fetching Strategies, Specifications, Mappings etc. The default behaviour in the spiking code is to enumerate the assemblies with the executing processes deployment.

Provide it all

For those that like the EDMX way of doing things and want to provide all the Fetching and Speciation instructions in line, this is the way to go about it:

public class CustomerBuyingStatusRepository : Repository
{
    public CustomerBuyingStatusRepository()
    {
        //BEWARE THIS STRING WONT COMPILE ITS MESSED UP
        //FOR THE PURPOSE OF VIEWING IN THE BROWSER.
        const string constring = “metadata=res://*/Northwind.csdl|res://*/” +
                                 “Northwind.ssdl|res://*/Northwind.msl;” +
                                 “provider=System.Data.SqlClient;provider “ +
                                 “etc, etc, etc”;

        this.IocContainer = new IoC();
        this.Session = new NorthwindEntities(constring);
    }
}

public void using_concrete_repository_entity_and_inline_spec_and_fetching()
{
    var customersStartWithA =
        new Specification<Customer>(c => c.CompanyName.StartsWith(“A”));

    var fetch = new FetchingStrategy<Customer>(true);

    fetch.AddIntentions(new IEagerFetchingIntention[]
    {
        EagerFetchingIntention.CreateInstance<Customer,
                                              ICollection<IOrder>>(c => c.Orders)
    });

    var repo = new CustomerBuyingStatusRepository();

    var custs = repo.Get<Customer>(customersStartWithA, fetch);

    foreach (var cust in custs)
    {
        Console.WriteLine(cust.CompanyName);
        cust.MakePrefered();
    }
}

I could have easily left out the ability to support this in-line method, given that the purpose of the spike was to proof the role based approach, having it’s greatest value proposition in being resolved dynamically against the Role. Nonetheless it is possible to mix and match or exclusively do either if you absolutely must. No prizes for guessing which mode I am more partial to, however I will reserve final judgement until it gets a good hit out in the real world, remember this is all the result of a brute force spiking effort.

What’s Left?

In part 3.0 we will look at concurrency and throughput through the lens of a service layer. I will also make the code download available in part 3.0.

Helping Entity Framework v4.0 play it’s <ROLE> - Part 2.0 is a post from: Living in the Tech Avalanche Generation