The best experiences I have had always seem to take root in groups (even as small as two) where debate of ideas were frequent and encouraged. Further to that, protagonists exhibit an ability to come to the debate without ego and a willingness to leave a position previously held when the debates logical outcome cannot support their position. I have in the past witnessed what I call the ‘developers mother Teresa effect‘ where a developer will hold on to their position when all else seems lost, purely out of a need to save it’s soul.

What was fantastic about today’s debate was that it started out around a single issue and flowed into a much broader discussion that lead to a great number of issues and solutions that had not yet been considered much less understood. So what started as a debate over a single topic ended with an array of solutions to a number of issues that were previously hidden - a very positive outcome all in all. Along the way we argued (debated) our viewpoints strongly but never was their hint of dying for a cause borne out of it’s ownership. In some small way it reminded me of TDD, in the sense that as a group we were able navigate an outcome from testing our opinions and ideas, in the same vein as one discovers the design of code through testing.

So what’s holding it (WPF) back? I have read and listened to a lot of stuff online suggesting it’s so complex that it’s turning people off the idea. So what about the issue of so called complexity? Of all the ‘W’ technology stacks to come out from Microsoft, I count WCF as the most complex and there certainly hasn’t been any overwhelming discussion about how that complexity has raised the barrier of entry, to the point where it’s slowed adoption. There seems to be an consistent message coming from the scribes, with constant reference to a new division of labour, shared by the trusty old developer and the so called ‘turtle necks’ (designers), a term that seems to be sticking and one I’m sure designers find amusing a pejorative one. And lets not forget the newest addition to the vernacular, the ‘Devigner’! There seems to be a lot of opinion and chatter that holds the opinion that UI design is no longer within our grasp as developers, unless we have enough right brain activity going on that we might be precluded from committing outrageous sins of the desktop.

So here’s my take – I have written a few UI’s now in XAML based technology (SL and WPF) and I do not count myself as a designer or devigner. Perhaps I have some artistic flair (yeah I’m an arty type) in a general sense, but when it comes to graphics, I am pure stick figures all the way. I have been known to classify myself in the past as the patron saint of the graphically challenged! And yet I have now developed a couple of XAML User Interfaces where the User’s and my peers considered them to be ‘attractive’, self describing, efficient, simple to use, etc. Oh, and I still managed to do this all with my trusty old supervising controller in tow.

So why didn’t I cower in corner somewhere at the prospect of building a XAML UI? Well it’s not in my nature for starters, but secondly I wasn’t prepared to believe the hype. Sure I did quite a bit of prototyping and experimentation but in the wash up, learning is doing and each time I do it I get better at it – sound familiar? By the way, I don’t think I was doing anything graphically amazing per`se, but some nice simple animations will go a long way even from the king of the stick men.

Here is what I advise: don’t be afraid of the technology. If you ever developed desktop applications in the past and considered yourself capable in designing a good user experience, then don’t buy into the scare mongering and be prepared to jump off the cliff.

I don’t doubt that there will be some small percentage of software teams that will bring on a dedicated designer(s) but I would hate to think that the small development teams out there will be put off venturing out into the brave new world. Yes there is a lot of complexity (particularly in WPF) and the learning curve is certainly not shallow by any means, but nothing good in life is easy.

In the past when I have been inspired it has always had a cause and effect relationship, I get inspired to *act* for a given cause or outcome. Sometimes this is a private affair and other times it’s a shared experience, nonetheless it’s always rooted in action, the effects of which are distinguished by a *reaction* (hopefully positive) from myself and other people with whom I interact.

There have been a few people along the way during my career in software development that have inspired me, some whom I have had the pleasure to meet and others whose teachings and ideas I have followed. In each case I have indeed been inspired to learn and grow. I have also had the privilege of working in groups where the individuals within were able to inspire each other through sharing a common goal. The latter of these types of experience I have found anecdotally to be increasing in frequency with respect to software development. It goes without saying that when I had a career in music this was far more commonplace.

K. Scott remarked in his post that:

“An inspirational book, in my mind, transcends any specific technology and makes you think differently about how you approach your job.”

a statement that for me rings true for any form of inspiration, whether it comes from books or other sources. I remember in my days as a music recording engineer / producer, I worked with artists and drew on the teachings Constantin Stanislavski (the father of method acting) to provide inspiration for character portrayal in live performance.

So what about you? Who inspires you? BTW, that’s a rhetorical question unless you see fit to share your answer.

The Saga Persister

It may be premature to discuss the Saga Persister without first touching on that which begat it, namely the Saga. I like to think of Saga’s as a long running stateful services, with methods for entry points that handle messages. You can also think of a Saga as a class that contains a set of methods, each one handling a different message type, where the entire Saga, it’s methods and all the logic contained within, accomplish a set of work over time. These methods make up the contract of what is ultimately a stateful service. For a lengthy discussion of Saga’s I recommend reading more from Udi here. In the meantime here’s a somewhat elided example:

public class RequestLeaveSaga : Saga<RequestLeaveSagaData>,
        ISagaStartedBy<IAnnualLeaveRequest>,
        IMessageHandler<IAuthorizationForAnnualLeaveResponse>,
        IMessageHandler<ICancelAnnualLeaveRequest>
{
    public override void Timeout(object state)
    {
        //…timeout logic here
    }

    public void Handle(IAnnualLeaveRequest message)
    {
        Data.Id = Guid.NewGuid();
        Data.LeaveRequestId = message.LeaveRequestId;
        Data.EmployeeId = message.EmployeeId;

        var leaveRequestForAuthorization =
            Bus.CreateInstance<IReqeustingAnnualLeaveAuthorization>(
            m =>
                {
                    m.EmployeeId = message.EmployeeId;
                    m.FirstDayOfLeave = message.LeaveStartsAt;
                    m.NumberOfDaysRequested =
                        Data.CalculateDays(message.LeaveStartsAt,
                            message.LeaveEndsAt);
                    m.TimeOfRequestSubmission = message.TimeOfRequest;
                    m.SagaId = Data.Id;
                });
        Bus.Send(leaveRequestForAuthorization);
    }

    public void Handle(IAuthorizationForAnnualLeaveResponse message)
    {
        //…handles the response message from a HR authorization service
    }

    public void Handle(ICancelAnnualLeaveRequest message)
    {
        //…handles cancel message to invalidate the request for leave
    }
}

The key to understanding the Saga Persister is linked directly to the statefulness of the Saga itself, where the job of the persister is to initially hydrate the Saga’s  state to storage (persistent or otherwise), so that when one of it’s subsequent message handlers (methods in its contract) are called, it can be re-hydrated from the storage. Saga’s contain a property named Data, which we can see (above) has been referred to in the body of the Handle method for the IAnnualLeaveRequest message. The underlying type for the Data property is determined generically in the signature for Saga<T> where T is an ISagaEntity. When persisting Saga state (to storage), NServiceBus will use the values it finds in the instance of <T> (the ISagaEntity reference in the Data property).

To better understand how this works lets look at the details specified in configuration of the Bus using the NServiceBus fluent interface for configuration, which resides in the process hosting the Saga. The following example is derived from the configuration of the Bus as demonstrated in the NServiceBus “Manufacturing” sample project.  In this example (below) I have substituted the “out of the box” persister (backed by NHibernate) with a Linq To SQL implementation.

try
{
    DataContext sessionFactory = GetContext();

    var bus = NServiceBus.Configure.With()
        .SpringBuilder(
            (cfg =>
            {
                cfg.ConfigureComponent<OrderSagaFinder>
                    (ComponentCallModelEnum.None)
                    .SessionFactory = sessionFactory;
            }))
        .XmlSerializer()
        .MsmqTransport()
            .IsTransactional(true)
            .PurgeOnStartup(false)
        .DbSubscriptionStorage()
            .Table(“Subscriptions”)
            .SubscriberEndpointColumnName(“SubscriberEndpoint”)
            .MessageTypeColumnName(“MessageType”)
        .Sagas()
        .LinqToSqlSagaPersister<OrderSagaData>(sessionFactory)
        .UnicastBus()
            .ImpersonateSender(false)
            .LoadMessageHandlers(
                First<GridInterceptingMessageHandler>
                    .Then<SagaMessageHandler>()
             )
        .CreateBus()
        .Start();
}
catch (Exception e)
{
    LogManager.GetLogger(“hello”).Fatal(“Exiting”, e);
}

There are two main areas of this configuration code that we should focus on. Firstly when we configure the nominated Inversion of Control container we can specify which Saga Finder to have configured and inject the required LINQ To SQL DataContext. Further down in this usage of the fluent interface I have specified that this endpoint supports Sagas and that they should use the LINQ To SQL Saga Persister and also that the same DataContext should be injected.

.Sagas()
.LinqToSqlSagaPersister<OrderSagaData>(sessionFactory)

namespace NServiceBus
{
    public static class ConfigureLinqToSqlSagaPersister
    {
        public static Configure LinqToSqlSagaPersister<T>(this Configure config,
            DataContext sessionFactory) where T : class, ISagaEntity
        {
            config.Configurer
                .ConfigureComponent<LinqToSqlSagaPersister<T>>
                        (ComponentCallModelEnum.Singlecall)
                .SessionFactory = sessionFactory;

            return config;
        }
    }
}

Implement an Interface

To create your custom Saga Persister you will need to implement an interface found in the NServiceBus library, unsurprisingly this Interface is named ISagaPersister and has four method signatures that make up it’s contract definition.

public class LinqToSqlSagaPersister<T> :
        ISagaPersister where T : class, ISagaEntity
{
    public void Complete(ISagaEntity saga)
    {
        SessionFactory.GetTable<T>().DeleteOnSubmit(saga as T);
        SessionFactory.SubmitChanges();
    }

    public ISagaEntity Get(Guid sagaId)
    {
        return SessionFactory.GetTable<T>()
            .Where(s => s.Id == sagaId).Single();
    }

    public void Save(ISagaEntity saga)
    {
        SessionFactory.GetTable<T>().InsertOnSubmit(saga as T);
        SessionFactory.SubmitChanges();
    }

    public void Update(ISagaEntity saga)
    {
        SessionFactory.SubmitChanges();
    }

    public virtual DataContext SessionFactory { get; set; }
}

The four methods of an ISagaPersister are responsible for interacting with the persistence store by getting a Saga entity by it’s ID, updating an existing saga entity, saving a saga entity and setting a saga as completed and removing it from the active saga list.

The Mapping File

In order to Map the ISagaEntity to the database tables we can take advantage of the fact that LINQ To SQL supports POCO’s and simply map our entities as required.

<?xml version=”1.0″ encoding=”utf-8″?>
<Database Name=”Sagas”
          xmlns=”http://schemas.microsoft.com/linqtosql/mapping/2007″>
  <Table Name=”dbo.OrderSagaData” Member=”OrderSagaData”>
    <Type Name=”OrderService.OrderSagaData”>
      <Column Name=”Id” Member=”Id” DbType=”UniqueIdentifier NOT NULL”
              IsPrimaryKey=”true” CanBeNull=”false” />
      <Column Name=”Originator” Member=”Originator”
              DbType=”VarChar(50)” CanBeNull=”true” />
      <Column Name=”PurchaseOrderNumber” Member=”PurchaseOrderNumber”
              DbType=”VarChar(50) NOT NULL” CanBeNull=”false” />
      <Column Name=”PartnerId” Member=”PartnerId”
              DbType=”UniqueIdentifier NOT NULL” CanBeNull=”false” />
      <Column Name=”ProvideBy” Member=”ProvideBy”
              DbType=”DateTime NOT NULL” CanBeNull=”false” />
      <Association Name=”OrderSagaData_OrderSagaDataLine” Member=”Lines”
              ThisKey=”Id” OtherKey=”OrderSagaDataId”
              Storage=”_orderLines”/>
    </Type>
  </Table>
  <Table Name=”dbo.OrderSagaDataLines” Member=”OrderSagaDataLines”>
    <Type Name=”OrderService.OrderLine”>
      <Column Name=”Id” Member=”Id” DbType=”UniqueIdentifier NOT NULL”
              IsPrimaryKey=”true” CanBeNull=”false” />
      <Column Name=”OrderSagaDataId” Member=”OrderSagaDataId”
              DbType=”UniqueIdentifier NOT NULL” CanBeNull=”false” />
      <Column Name=”ProductId” Member=”ProductId”
              DbType=”UniqueIdentifier NOT NULL” CanBeNull=”false” />
      <Column Name=”Quantity” Member=”Quantity”
              DbType=”Float NOT NULL” CanBeNull=”false” />
      <Column Name=”AuthorizedQuantity” Member=”AuthorizedQuantity”
              DbType=”Float NOT NULL” CanBeNull=”false” />
      <Association Name=”OrderSagaData_OrderSagaDataLine” Member=”Order”
              ThisKey=”OrderSagaDataId” OtherKey=”Id”
              IsForeignKey=”true” Storage=”_order” />
    </Type>
  </Table>
</Database>

To make the mapping file work with the DataContext instantiation we need to do something like the following:

private static DataContext GetContext()
{
    StreamReader sr =
        new StreamReader(“D:\\SagaL2SMapping.xml”);

    //set the mapping source up
    XmlMappingSource mapping = XmlMappingSource.FromStream(sr.BaseStream);

    DataContext db = null;

    //new up a persistance repository
    db = new DataContext(“Data Source=BOOMER\\BOOM09;initial “ +
                        “catalog=Sagas;user id=sa;password=supremo”,
                         mapping);

    var loadopts = new DataLoadOptions();
    loadopts.LoadWith<OrderSagaData>(o => o.Lines);
    db.LoadOptions = loadopts;
    db.DeferredLoadingEnabled = false;

    db.Log = new DebuggerTextWriter();

    return db;
}

The Saga Finder

The final part of the puzzle is the Saga Finder which is dealt with by implementing the class IFindSagas<T>. The IFindSagas class contains a nested interface Using<M> which indicates to NServiceBus that implementers of IFindSagas<T> have the ability to find saga’s of the type <T> where the message being handled is of type <M>. Once again using the “manufacturing” sample from the NServiceBus download, I have implemented a Saga Finder using LINQ To SQL:

public class OrderSagaFinder :
    IFindSagas<OrderSagaData>.Using<OrderMessage>,
    IFindSagas<OrderSagaData>.Using<CancelOrderMessage>
{
    public OrderSagaData FindBy(OrderMessage message)
    {
        return FindBy(message.PurchaseOrderNumber, message.PartnerId);
    }

    public OrderSagaData FindBy(CancelOrderMessage message)
    {
        return FindBy(message.PurchaseOrderNumber, message.PartnerId);
    }

    public OrderSagaData FindBy(string purchaseOrderNumber, Guid partnerId)
    {
        return sessionFactory.GetTable<OrderSagaData>().Where(
            o => o.PurchaseOrderNumber == purchaseOrderNumber &&
                o.PartnerId == partnerId).FirstOrDefault();
    }

    private DataContext sessionFactory;

    public virtual DataContext SessionFactory
    {
        get { return sessionFactory; }
        set { sessionFactory = value; }
    }
}

The Using<M> interface in NServiceBus specifies a single method in it’s signature, which you probably guessed is:

T FindBy(M message)

So, off we set and created our prototype and when completed, sent it on to the stakeholders to cast their critical eye upon it and provide feedback using the SketchFlow players tools for capturing feedback. I must admit that I wasn’t convinced that our users / stakeholders where going to be particularly enamoured by the experience but I am happy to say that I was wrong- so incredibly wrong. Whilst developing the prototype I found myself continually applying my own biases toward the tool and they were such that I was developing an opinion that SketchFlow’s feedback mechanism was a little too simple and perhaps even ‘clunky’ to provide them with an experience that they would consider productive or enjoyable. However, the feedback came through very swiftly and along with it an enormous endorsement of the process, tool and the whole experience.

These user / stakeholders are used to defining and or changing a proposed UI layout in well known visual design applications (unnamed) and feeding those design documents accompanied with text documents (for annotation) to the software team for consideration. These documents would bounce between parties until a finalised design had been settled upon.

This time, upon having been supplied feedback via SketchFlow, they are reporting a significant amount of saving in time dedicated to the process and they are attributing that time saving entirely to the ease of use and functionality of SketchFlow. Now it’s early days yet and I don’t want to get carried away until we get a few more iterations into the process, however I am feeling pretty excited when our users come back with such positive feedback in their experience of the whole development life cycle.

And there I was, ready to put the kybosh on the idea. I cant argue a case when the business stakeholders show you nothing but thumbs pointing in an upward direction.

If you would like to register for the event please send me an email here. There are only 10 seats available so get in quick. Whilst the program is offered at no charge, a $5 dollar donation from attendees will go along way to defray the cost of the community centre room which is decked out with PC’s for each attendee. The venue is the Point Cook Community Learning Centre in the Western Suburbs of Melbourne Australia.

UPDATE:

Check the comments to see how many seats are still available.

This is not the first time this has happened to me, in fact I have dreamt code a dozen or so times before and it’s always during unsettled nights where I would awake several times with the same code reverberating in my head. I have asked colleagues about this a few times and have found that one or two of them have also experienced this phenomenon and a bit of research seems to indicate that I am not alone (which I expected). What about you – do you dream code?

As I said at the top of this post, we are already reaping some benefit and there is certainly not an Python guru amongst us (yet). Most recently we were asked for a fairly trivial application (as far as complexity goes) but one that was very valuable to the business nonetheless. Without going into the gory details, what was requested was a desktop application that digitally processed documents (imaging) and produced the output fast, and I mean really fast. The last part of the request was for a design that would allow the document list to be compiled from almost any source, database, xml, Microsoft Office files, txt, etc etc. Let’s deal with each of these concerns in order of their being mentioned.

Steroidal Processing Speed

This part was really not that hard to design and the choice was a simple one, in one word, NServiceBus. What was needed essentially was many workers all doing the same work on a given set of files and this of course mapped brilliantly to one way messaging using NServiceBus and it’s distributor to manage balancing the load amongst the workers. By spreading out the work across any number of worker nodes, our project managers could scale up and down according to their needs to adhere to a given SLA. If you want to read more about the Distributor in NServiceBus please check out Ayende’s review.

Convention to the Rescue

As I said earlier, we were asked to provide a method of very quickly adding or “plugging in” new ways to access data that would produce the list of files for processing  and furthermore this needed to work without needing to recompile any part of the application. Given these conditions and the convention that our messages were always derived from data that included a list of files to be processed, it was pretty clear that IronPython was a perfect fit.

The UI itself was built using C# with the exception that the list box contents would be populated by an IronPython script and the same script would call-back into the C# code with the list of results (file paths). Having IronPython scripts call-back into managed code is trivial, you just need to pass a function from the executing managed assembly and have that function stored as a variable on the executing Script Scope. Then you just call the function. For example:

public void callback()
{
    Debug.WriteLine(“Test Callback method got called”);
}

public string funcback(string calledwith)
{
    Console.WriteLine(“Test Callback function got called with “ +
        calledwith);
    return calledwith;
}

private void SetDefaultScopeVariables(ScriptScope scope)
{
    scope.SetVariable(“test_callback_method”,
        new Action(callback));
    scope.SetVariable(“test_callback_function”,
        new Func<string, string>(funcback));
}

What the sketch of the UI (above) points out (see the red arrow), is that by dropping scripts into the application we were able to load up any number of ways in reading data to produce the list of files that would be used in creating our messages (sent via the distributor). So by simply dropping in a new IronPython script, another item would be loaded into the list box, offering a new method of accessing data requiring processing. Every scripted plug-in would provide an input, a description and it’s own particular method of accessing data (which could be anything).

On a side note, the UI sketch was produced using SketchFlow in Expression Blend 3 which looks quite promising.

I have an itch. A modelling domain specific language itch. I must say that my interest in new languages has been reinvigorated of late and this has seen a flurry of activity around the DLR, IronRuby, IronPython and now most recently the M family of languages via my curiosity in what Oslo has to offer. I haven’t yet delved nearly as far as I intend into M and Oslo, however from what I have seen I must admit I am interested in the possibilities that (small) DSL’s might offer, particularly in the vertical I happen to work in.

HOWEVER

My grandfather had a great saying for when he or other people seemed to find themselves in a state of confusion, he called it “oogle boogled” and I have to say that after Doug Purdy’s latest post I am feeling a bit that way right now. My read on things is that Microsoft seem to be placing “M” and Oslo adjacent to a war cry of  “DATA, DATA, DATA, DATA” and hence the announcement that:

“the modelling platform is aligned in a deep and fundamental way with the data programmability stack (ADO.NET, EF/EDM, Astoria, etc”

Doug also goes on to announce that the teams have come closer (much) together, with:

“we made a decision to merge the Data Programmability team (EDM, EF, Astoria, XML, ADO.NET, and tools/designers) and the “Oslo” team (“Quadrant”, Repository, “M”) together”

What Interested me in the first place?

The piece that interested me mostly about Oslo was MGrammar and building textual DSL’s. The reason was simple, I work in a industry where we have a throng of ‘Data Managers’, where I (and others) are engaged in building tools that help these guys manage data. These ‘Data Managers’ are by definition pretty data savvy and tech literate. The potential for the DSL’s in this space largely revolves around tool aids and even the ability to code gen workflow and deployment instructions. So in short I look forward to seeing what the possibilities are with writing DSL’s that produce navigable models and from there it’s a land of unknown promise. Of course to the Eclipse community this is nothing new, but for an old Visual Studio hack like me, it’s a brave new world.

My concern is that if the focus swings deep enough into the “DATA DATA DATA DATA” mantra, somehow the potential for what excited me about the Oslo initiative will perhaps be diminished in it’s significance. I am certainly not stating this to be case, only that it’s a concern of a dilatant, (me), on his way to becoming enlightened. Perhaps misunderstanding on my part and perhaps lost in the articulation on theirs?

Interest in the event is growing quickly and we hope to be in a position to lock down the date very soon. We are getting close to having the numbers for a definite date of the week of October 26, therefore if you are interested in taking part, now is the time to start thinking about aligning the stars and putting your ducks in a row (so to speak).

If you are interested in attending the event, please contact Techavalanche to enquire with your details and register your interest on the poll and we can make sure you don’t miss out on what should be a week to remember.

Ans: Yes!

Question: Can I use my C# classes from IronPython (in the IP runtime)?

Ans: Yes!

Question So, I should be able to use my C# classes in a multiple inheritance scenario from IronPython?

Ans: Yes!

Making it all work

If you create a class in managed C# you are free to pass it along for use to the IronPython runtime and thus access it using IronPython. Let’s take the following class created in C#:

public class Person
{
    public string Name;
}

Using my IronPython WPF interactive console control, I can interactively create new classes with IronPython and use my C# Person class as the base class in an inheritance object graph. Here’s the code as typed at the interpreter:

As you can see, first up I imported the relevant namespace (module) where the C# Person class is defined. The first class derived from Person is Employee and then I have derived WarehouseManager from Employee which leaves our Inheritance tree like this:

• Person
  • Employee
    • WarehouseManager

You can also see that both the derived classes have access to the Name property of the C# Person class which proves that the Person class has been included in the inheritance of the Employee and subsequently WarehouseManager classes.

So that’s some plain old inheritance using C# classes. Now lets take a quick look at multiple inheritance using the same C# class.

When should I use this feature?

Probably never according to some people, yet for every objector there seems to be fan. Languages that do support multiple inheritance, often come with a disclaimer for programmers to avoid their usage and Python would appear to be no exception in this case. The above is a good example of why multiple inheritance isn’t necessarily a good thing, given that a manager is presumably an employee and at the very least a person. Nonetheless it demonstrates the intent and this post isn’t so much about the ‘why’ but mostly for now it’s about the how. I will follow up soon with more about the ‘why’ and ‘when’ in a subsequent post.

Carefully managed, I can see it’s potential uses could be enticing. Yes, yes I know “composition over inheritance” etc…There is never one shoe fits all!

Just in case you where wondering

If you were thinking of doing something like this in C#:

public class WidgetA
{
    //….etc
}

public class WidgetB
{
    //….etc
}

Followed up by:

You will see that we cant in fact use two classes created in a CLI compliant language. This will effectively stop crazy stuff like this:

class MutantUi(Form, Button):
    def SetTitles(self):
        self.Text = “What happens here“

But I am completely free to do this:

from Org.TechA.Wpf.ControlsHarness import *

class PythonMixin(object):
    def method(self):
        print ‘method‘

class Mutant(PythonMixin, Person):
    def MutantMethod(self):
        print ‘mutant method‘

 m = Mutant()
 m.method()
 m.Name = “Simon“
 print m.Name
 m.MutantMethod()
 

So there you have it, Multiple inheritance / mixins with C# (well kinda)!

Doing .Net Days will focus on a variety of programming topics, mostly as they relate to programming on the .NET platform and covering technologies that touch both the CLR and DLR.

Doing .NET Days will also give a great deal of it’s ‘Air Time’ to topics that feature heavily in the Alt.Net space. Open Source frameworks and tools will also be covered extensively and if you have stopped by here before you would know that our very first event will include a discussion and demonstration of nServiceBus, a framework (fast growing in popularity) designed to make building distributed systems easier.

Classic Python Version

print “should I use python functions or .Net?“ +
                    “Ans = %(yes)s“ % {‘yes‘: ‘yes‘}

BCL Centric Version

print String.Format(“should I use python functions“ +
    “or .NET? Ans = {0}“, “BCL Functions“)

So that was pretty trivial. What about File access?

Classic Python Version

 rdrp = open(r”c:\Document1.txt“)
 rdrp.read()

BCL Centric Version

 rdr = StreamReader(r”c:\Document1.txt“)
 print rdr.ReadToEnd()

Any clearer on a choice? The pragmatist in me says use the BCL and the purist says use the python standard libraries. So how heavy should our BCL wielding hand be? This leads me nicely to the next question, how exactly should we go about learning a Dynamic .NET Language? Surely this process will help us make up our minds about when to use the BCL and when not to? Something tells me that the answer lies pragmatically somewhere in the middle ground? The kind of meat and potato stuff like that demonstrated above is likely going to have me opt for the classic Python approach as my default position, however I am not going to put myself to the trouble of working with databases for example without the help of ADO.Net. To help myself form my own opinions I decided that the best learning path for me was as follows:

1. Read the Python 2.5 (CPython) documentations PDF Tutorial and re-type it’s code examples and follow with my own experimenting.
   • This allowed me to get a fairly good overall feeling for the language.
2. Read IronPython in Action to get a good overall point of relevance to .NET and see how the power of .NET as a platform would impact the Python experience and visa versa.
3. Read Python is a Nutshell and get a grasp on Python’s roots and how the language is best put to use on it’s original platform (the C implementation).

Some people will surely think that points 2 and 3 should be reversed? Perhaps, but my rationale for taking this approach is that Python is not likely to become a daily instrument in my work and I want to understand as much as possible about it in the .NET world first. I do believe however that to truly understand the power of Python I will need to learn deeply about its roots and oddly I suppose that step in the process will come last.

For more information please see this poll and register your interest. Also feel free to contact me @here. For more information on the course content check this link out.

Fetching Strategies are a key concept when considering tuning your data access code in Event Driven Architectures. By using ‘roles’ to explicitly fetch data either eagerly, lazily or some combination thereof, we can build fetching strategies to load accordingly when a role has been specified. The role can be reasoned as a business event of sorts. Udi has written extensively on this and developed a method for using fetching strategies with NHibernate and if you haven’t yet checked out what he’s had to say to date on the subject I suggest you take a look.

With Entity Framework 4.0 I wanted to refine my approach taken with EF 1.0 previously. Fetching Strategies are a key component in the framework (which I call NFetchSpec4Ef) and helps me work in a manner that fit’s with my use of Domain Driven Design.

Demonstrate your intentions

Before we get to the strategies themselves we need some way to state our intent with regards to fetching data and so this leads us to Fetching Intentions.

public class EagerFetchingIntention
{
    private static EagerFetchingIntention _factory_intent;
    private readonly string _fetchAssociate;

    public string FetchAssociate
    {
        get { return _fetchAssociate; }
    }

    internal EagerFetchingIntention(string fetch)
    {
        _fetchAssociate = fetch;
    }

    private EagerFetchingIntention() { }

    public static EagerFetchingIntention
            CreateInstance<TRootEntity, TFetchEntity>
            (Expression<Func<TRootEntity, TFetchEntity>> fetch)
    {
        if(fetch == null)
            return new EagerFetchingIntention(string.empty);

        int dot = fetch.Body.ToString().IndexOf(“.”) + 1;
        string includes = fetch.Body.ToString().Remove(0, dot);

        _factory_intent =
            new EagerFetchingIntention(includes);

        return _factory_intent;
    }
}

We can chain intentions together with a fluent interface provided by an .And()extension method.

public static class EagerFetchingIntentionExtensions
{
    public static EagerFetchingIntention And(
                this EagerFetchingIntention original,
                EagerFetchingIntention addTo)
    {
        EagerFetchingIntention compound_intention;

        compound_intention =
            new EagerFetchingIntention(
                original.FetchAssociate +
                “.” + addTo.FetchAssociate);

        return compound_intention;
    }
}

Fetching Strategies Refactored

Like all parts of NFetchSpec4Ef, Fetching Strategies needed to be rethought as part of addressing the 4.0 changes to the Entity Framework and in particular it’s new support for POCO entities and (somewhat) implicit lazy loading. So what do Fetching Strategies look like now? Fetching Intentions remained (as seen above) but generally speaking the API changed somewhat.

public interface IFetchingStrategy
{
    IList<EagerFetchingIntention> Intentions { get; }
    IEnumerable<string> Includes { get; }
    void AddIntentions(EagerFetchingIntention[] intentions);
    bool ShouldLazyLoad { get; }
    bool HasInstructions { get; }
}

public interface IFetchingStrategy<TRole> : IFetchingStrategy { }

These two interfaces form the basis of Fetching Strategies in NFetchSpec4Ef. In the next version of NFetchSpec4Ef, the implementation no longer required implementing these interfaces directly when creating a new strategy, rather we inherit from a super class that has already done this for us. You might also notice that the aspects to this interface for non-public consumption have been hidden through explicit implementation.

public class FetchingStrategy : IFetchingStrategy
{
    private readonly IList<EagerFetchingIntention> _intentions;
    private readonly bool _includeDeferedLoading = default(bool); 

    public FetchingStrategy(bool useDeferedLoading)
    {
        _includeDeferedLoading = useDeferedLoading;
        _intentions = new List<EagerFetchingIntention>();
    }

    private FetchingStrategy() { }

    public void AddIntentions(EagerFetchingIntention[] intentions)
    {
        if ((intentions == null) || (intentions.Count() < 1))
            return;
        intentions.ToList().ForEach(i => _intentions.Add(i));
    }

    public IEnumerable<string> Includes
    {
        get
        {
            if(((IFetchingStrategy)this).HasInstructions == false)
                return new List<string>().AsEnumerable();

            IEnumerable<String> includes =
                (from intents in _intentions
                select intents.FetchAssociate).AsEnumerable();
            return includes;
        }
    }

    IList<EagerFetchingIntention> IFetchingStrategy.Intentions
    {
        get { return _intentions; }
    }

    bool IFetchingStrategy.ShouldLazyLoad
    {
        get { return _includeDeferedLoading; }
    }

    bool IFetchingStrategy.HasInstructions
    {
        get { return _intentions.Count > 0 || _includeDeferedLoading; }
    }
}

Our goal includes notifying our infrastructure of our fetching intent by being explicit through the use of roles which have been defined as Interfaces. The infrastructure is able now to employ IoC / DI to locate the most appropriate Fetching Strategy from a container. This frees us to swap out fetching details for specific business events, after all, in some situations such as “IMakeCustomerPreferred” (see below), I might want to eager fetch all my customers orders and order lines in one go. Here’s the base class implementation of IFetchingStrategy<T> for role based fetching strategies,  followed by a custom Fetching Strategy:

public abstract class FetchingStrategyForRoles<TRole> :
        FetchingStrategy, IFetchingStrategy<TRole>
{
    public FetchingStrategyForRoles(bool useDeferedLoading) :
        base(useDeferedLoading) { SetupIntentions(); }

    public abstract void SetupIntentions();
}

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

    public override void SetupIntentions()
    {
        var orders_intention =
            EagerFetchingIntention
            .CreateInstance<Customer, IList<Order>>(c => c.Orders);
        var orderlines_intention =
            EagerFetchingIntention
            .CreateInstance<Order, IList<OrderLine>>(o => o.OrderLines);

        var iFetch = this as IFetchingStrategy;

        iFetch.AddIntentions(new EagerFetchingIntention[]
            {
                orders_intention,
                orders_intention.And(orderlines_intention)
            });
    }
}

var repo =
    new EntitiesRepository<NorthwindEntities, Customer>
        (new NorthwindEntities());

repo.Get<IMakeCustomerPreferred>();

We leave the container (IoC) to deal with locating the right fetching strategy based on the role of IMakeCustomerPrefered. The dependency injection happens inside of the Repository.

The next part of NFetchSpec4Ef to discuss will be how Specifications fit in and what they offer to Repositories.

I am not going to regurgitate the changes here, for a complete list of the changes and new features see the ADO.Net Team blog.

There seem to be several points along an axis of how POCO you can choose to be with Entity Framework 4.0. At this stage I have the feeling that I will fall into the camp that probably wont use the proxies for change tracking but I will reserve judgement on that and perhaps that decision will be best left as a case by case assessment for some.

The thing I like the most is the fact I can (as already stated) remove the smoke and mirrors from my past efforts to get (somewhat) transparent lazy loading and streamline my whole approach. I say ‘somewhat’ transparent due to the fact that DeferedLoading is still ultimately ‘opt in’ and hence if you wanted to be pedantic you could make a case that this is still explicit. See below.

context.ContextOptions.DeferredLoadingEnabled = true

I will follow up from this post will several more by examining  each constituent part in the new version of NFetchSpec for the Entity Framework version 4.0. NFetchSpec4Ef, provides a reusable approach to implementing Repositories, Fetching Strategies and Specifications. Fetching Strategies provide a unified way of declaring your intent when instructing the Entity Framework to fetch data. Specifications enables a functional approach to supplying dynamic query predicates and stays true to the patterns original intent, that being to provide a means to testing that an entity satisfies a given set of conditions. Repositories speak for themselves.

Looking forward to seeing everyone there.

You can find more details about the event here and here.