Chris Cyvas

For the next rev of dashCommerce, we are going to be using NHibernate and so I have been exploring ways to both: 1.) get up to speed with NHibernate and 2.) the fastest way to get started working with NHibernate. I had seen all of the articles on Fluent NHibernate, but to me it just looked like a C# version of Xml. That’s not a ding against, it, but when you have system with about 50 tables in it, well . . . typing is typing.

But, one thing that caught my eye when I started looking around the Fluent NHibernate project was the AutoMapping feature. This feature will allow you to set up some conventions for use against your database and it will attempt to generate the mapping files for you. That’s pretty slick. But would it work well enough to actually use since Fluent NHibernate is still pretty young?

Well, it worked well enough for me.

So, here is what I had to do to pull it off against the dashCommerce database.

When I started trying to get the mappings to work against a bunch of dashCommerce tables, I was getting some errors about not being able to map certain entities. So, as soon as I saw that, and recognized that the exception wasn’t going to help me identify what, exactly, the problem was I dug into the code and ended up changing this very simple line in the ClassMap file (public void ApplyMappings(IMappingVisitor visitor)) around line 195: Debug.WriteLine(writer.ToString()); to Console.WriteLine(writer.ToString()); I was using a small console client with some sample queries in it, so this was best for me at the time. But, once I did that, I was able to quickly look at that output and determine the cause of my pains.

To be exact, they were all related to a few key things:

1. The AutoMap functionality relies on conventions to determine the structure of your database tables.
2. I had to update the AutoMap conventions with the conventions used by the dashCommerce database.
3. The dashCommerce database was not entirely consistent in its naming conventions. (gufaw!)

This last one is the one that really appealed to me as I know I put a lot of work into being consistent in the way the dashCommerce database is constructed, but it just showed me where I had missed things. This is great, and showed me the beauty of the AutoMap functionality. And it will be helpful in generating an upgrade script for dashCommerce going forward to ensure the database conventions are consistently applied.

So, how much code did it take to get the AutoMapping functionality working with dashCommerce? Not much. It’s not at 100% coverage yet, but we are in pretty good shape.

One other interesting thing about the AutoMapping in combination with dashCommerce is that in the dC database, we kind of namespace things out so there is a correlation between the assemblies and the database. For instance, we have the following naming conventions: dashCommerce _Core_tableName, dashCommerce_Store_tableName, and dashCommerce_Content_tableName. I’m still hmm’ing and haw’ing over whether or not I really like that anymore, but it does make things very clear for the developer that is customizing dashCommerce. That means it made the conventions less flexible, so I had to accommodate that in the code by creating separate files for each mapping. So, for instance, in getting the Core up and running, the code for Fluent NHibernate AutoMap was as simple* as this:

var configuration = MsSqlConfiguration.MsSql2005
    .ConnectionString(connectionString => connectionString
    .Server("MYSERVER")
    .Database("DASHCOMMERCE")
    .Username("USER")
    .Password("PASSWORD"))
    .UseReflectionOptimizer()
    .ConfigureProperties(new Configuration());

var autoPersistenceModel = AutoPersistenceModel
    .MapEntitiesFromAssemblyOf<Log>()
    .Where(type => type.IsClass && !type.IsAbstract && type.Namespace == "Core.Entities")
    .WithConvention(convention =>
    {
    convention.FindIdentity = p => p.Name == p.DeclaringType.Name + "Id";
    convention.GetTableName = type => "dashCommerce_Core_" + type.Name;
    convention.GetPrimaryKeyNameFromType = type => type.Name + "Id";
    convention.GetForeignKeyNameOfParent = prop => prop.Name + "Id";
    })
    ;

 autoPersistenceModel.Configure(configuration);

*simple took me a couple of hours, but that was digging into Fluent NHibernate for the first time and trying to grok and learn all at once.

There is still some work to do on Many to Many relationships, but this was darned impressive and a huge boost in productivity for dashCommerce and NHibernate. Thank you to the folks that have created Fluent NHibernate, this makes working with NHibernate easier than any other ORM / code generation tool out there.

One other side note worth mentioning is that once you have the AutoMap set up correctly, you can have Fluent NHibernate spit out the mapping files so that you can use those directly (which is what we are doing for dashCommerce).

Open source in the Microsoft ecosystem is a new thing, and to be frank, it’s only gaining ground in some areas of Microsoft. We’ve all heard the news reports of Steve Ballmer saying Open Source is Microsoft’s primary threat, among other things. I’m not here to re-hash all that. You either side with Microsoft, Open Source, or you are somewhere in between.

But, I am here to take Microsoft to task on one specific area where it’s open source strategy is sorely lacking, and that is in the funding or sponsorship of open source products built for the .NET platform. To the best of my knowledge, Microsoft does not sponsor any open source projects, yet they fully reap the benefit of open source developers that build on the .NET platform. We help propagate and evangelize the platform. If you take a look at Sun, they are well entrenched in sponsoring and organizing the sponsorship of third-party open source initiatives. That is a huge win for Sun and the Java community.

Microsoft’s behavior on this front has been pretty sophomoric to this point. A good example of this was Oxite. I’m not up for re-hashing all of that, but suffice to say it flops, and instead of sponsoring the project via some third party (to begin with), they build it internally, and then ask the community to fix their mess. The result of that was a pretty quick backlash from the community that said, “Hey, we’ve got jobs, and bills to pay, we aren’t here to clean up your code.” I honestly believe that was a bit of a reality check for Microsoft and the few open source proponents inside of Microsoft. My guess is that they let their ego’s get ahead of them on that one and were taken off guard by the community’s response, which IMHO, was spot on.

The .NET open source community is maturing and they are beginning to see the gaps between Microsoft’s behavior and the behavior of other open source proponents, such as Sun, and they are recognizing that much of what they are seeing is business as usual at Microsoft. Their attention to open source, to this point, has been in an effort to either 1.) Evangelize their platform or 2.) Harness the power of the open source community in an effort to make their products better. Any open source .NET application is firmly in #1, and things like the Enterprise Library fall into #2.

Microsoft has hired a few open source developers from the .NET ecosystem, but I’ve got some pretty un-easy feelings on that. Most of them are heavy bloggers and over the last several months, those developers’ blogs / podcasts have now become an evangelism platform for Microsoft’s latest initiative. The MVC framework is a perfect example of Microsoft failing to sponsor the Castle framework. They make the argument that “our customers want products by us, and only us”, but what their clients really want is stable products by stable companies. A company that Microsoft could be helping to create by sponsoring them like Sun does.

Is it Microsoft’s job to sponsor open source initiatives? No, not really, but there is a huge upside that they are ignoring when deciding against sponsorship, and that is this: they are foregoing the opportunity to have significant growth engines “close to the vest”, ready to be cherry picked, or perhaps just as well is the community good will that would result from such sponsorships. Microsoft really shouldn’t ignore this, as it is their main Achilles heel – lack of goodwill from segments of the community. If they want their development tools to be the tools to develop with and they want Windows to be the platform to deploy solutions on (open source and otherwise), then they need to consider, very carefully, how they expect to achieve that. You’ve got to do more than release open source software, or engage the community in building some open source frameworks; you have to get out in the community and help build the ecosystem that is going to support you over the long term.

I’ve never met Miguel de Icaza, but I found this interview and it is quite possibly the most intelligent interview I have listened to in the last few years. He’s an extremely “balanced” individual, fair and accurate. I like that. No, I don’t like it, let me re-phrase: It’s important to me. If you are looking into Mono and want to get a feel for the guy behind it, then this is the interview you should listen to.

Wow.

Note: Pay attention to the part about the Mono compiler being a service to allow dynamic C#. Now. Today.

In an nutshell the plan is to do 1 or 2 releases that tighten up the existing code base in 2009. We won’t do too many drastic things as there doesn’t appear to be a need based on the community feedback. There are some things here and there, but overall the feedback has been overwhelmingly positive.

What does it mean in the not-so-near term? Well, dashCommerce is going to move towards an enterprise solution. What does that mean? It means a lot of things, but mainly it means we are going big. Huge. Enormous. Why are we going to do that? Because my spidey sense is tingling. And I’ve been fortunate enough to see things recently that I have not seen before and the end result of that is a focus on going enterprise with dashCommerce. The enterprise edition will also have a more liberal licensing model – the kind that makes developers happy. More on that to come.

We are also going to focus on making Mono a first class, supported platform for dashCommerce. What does that mean? It means dashCommerce will be cross-platform: Windows, Linux, OS X, and BSD. Why? Well, we need a broader base and being able to run only on Windows is a limiting factor. It’s the same reason people program in Ruby, PHP, Perl, etc. – they can run anywhere. Will this piss off Microsoft? Dunno. I doubt it, since they made it possible. I think we will also see a huge upside from a community that is well experienced and entrenched in the open source world as we bring in developers from the Linux world. (fingers crossed)

I’d love to hear your thoughts on the direction we are taking and if you have any pointers, I’d love to hear those as well.

Oh, one last thing, I want to make the engineering of dashCommerce v.Next very transparent, so I want to do some screencasts as we move through the process. I’d like you to be a part of that. I’m looking for a broad range of talent, skill, etc. So if you think you have something to contribute, let me know and we can set something up. If you are interested in sponsoring the development of dashCommerce v.Next, please drop me a note here or send me an email or PM me in the dashCommerce forums (user id chris.cyvas).

Onward and Upward!