.Net lagging behind Java in ORM adoption, maybe

I just did a quick search on Dice for C# jobs seeking NHibernate experience and compared it to the number of listings looking for Java and Hibernate experience.  This is far from scientific and does not take into consideration any overlap in job listings (we all know how recruiters post jobs on the internet), other ORMs, VB.Net, or the fact the Java camp embraced ORMs much earlier than the .Net side.

With that said, here are the results.  For Java, 1144 of the 8908 (12.8%) listings mention Hibernate.  On the C# side, only 62 of the 4501 (1.4%) listings mention NHibernate.

I must say that I was surprised by the low percentage for Java/Hibernate since it has been around so long and everyone I know working with Java use Hibernate.  Maybe recruiters don’t mention Hibernate because it is so engrained that experience with it is assumed.

I am not surprised by the low C#/NHibernate numbers given the years of poor guidance given by Microsoft in this area and the initial lack of support for the OSS community.  I do expect this number to increase as more and more developers hear about ORMs and investigate  EF/linq2Sql alternatives.

Structural Design Pattern Confusion

The other day my team was having a discussion about some software we were working on.  During the discussion, several of the structural design patterns were mentioned, sometimes interchangeably. This is a brief overview of  three of them for future reference.

The Facade

The Facade defines a single, simplified interface over one or more subsystems.  Common usage of this is simplifying a remote system’s interface.

The Adapter

The Adapter changes (aka adapts) the interface of a class to match what is expected by a caller.  I have used this in the past to provide a common interface for getting/setting the value of web controls.

The Proxy

The Proxy stands in for another class, intercepting the call and then usually passing the call on to the class the proxy is representing.  Common usage of this is a proxy defined for WCF service or an NHibernate proxy for lazy loading.  The end result is additional behavior, like remoting complexities or lazy tracking, are injected into the the call stack without the user of the proxy having to know about it.

An Integration Story

My current project has me building a system to allow an external partner to integrate with our order application.  Right now, the end users have to go out to the partner’s site, get a list of new orders and manually enter them into our system.  The entire process is inefficient and distracts people away from their normal duties.  When complete, the integration will allow the partner to send orders directly to our system without human intervention (in most cases).

There are several ways to do integration.  Enterprise Integration Patterns outlines 4 at the start of the book: File Transfer, Shared Database, Remote Procedure Invocation (RPC), and Messaging.  We chose a mix of RPC and messaging.  The RPC via web services was selected as the way we communicate with the partner mainly because the partner already has an infrastructure built around web services.  Internally, we use a mix of web services and pub/sub messaging via MassTransit.

The architecture for the solution has four main parts: an external facing web service that the partner calls, a windows service for workflow (MassTransit saga) and integration business logic, a web service into our primary application, and a web service the external partner hosts for us to send updates to. There are many benefits to this architecture.  The external facing web service can be placed in a DMZ which only allows inbound calls to be routed to MSMQ, the windows service can be taken offline for maintenance without affecting the partner’s ability to send orders, loosely coupled components with clear and distinct responsibilities, and each part can be scaled independent of the other parts.

The order process is kicked off by the partner calling our web service and sending over a message for a new order.  In addition, the partner calls the web service once for each line item on the order.  Our web services takes data from these calls, transforms it into an object model, validates the data, and publishes messages via MassTransit.  The windows service has a saga that consumes the messages from the web service.  When the saga determines all the pars of an order have arrived (the order  and its line items), it calls a web service in our primary application to create the order.  At this point, the users can go in and do what they do with the orders.  As the orders progress thru the order application, messages are published about state changes.  The saga in the windows service consumes these messages and sends updates back to the partner’s web service.

In the end, the integration should add significant business value by increasing the overall efficiency of our employees and reducing errors caused by manual data entry.

Introduction, Say Hello

So I have decided to get more involved with the community by blogging.  This is my introduction to the world.

My name is James and I am a software developer in central Texas.  My professional interests include enterprise integration, custom application development, agile processes and general best practices.  Personal interests are my family, hiking/camping, fitness and healthy living, and snow boarding.

The majority of my posts will focus on my professional interests, products I use, and the discussions I have about technology.  Through this blog, I hope to spark constructive discussion, help people solve problems, and introduce others to the concepts/topics I consider important to my career.

Thanks for reading and please bare with me as I improve my writing ability.