I am working on a project for a client that is a little different to others that I have done. It is a simple project which needed two winforms applications. One was to be used by all and sundry, and the other was uesed by the project administrators.
I could have used one application, and usually I would have done so. Except that the first application was to be run on a system with a touch screen. I didn’t want a bunch of menus and a login screen for administrators. It was simpler to just write two applications.
The other difference with these apps from others that I am used to is that they use a MySql database. In the past all the applications I have written in the .Net world have used either MsAccess or SqlServer. Fortunately, the Access apps have been getting fewer, although I do have one on the go at the moment, and that is also a painful experience which I will write about in a subsequent post.
The problem with MySql is the data providers. I use an Object Relational Mapper for database access whenever I can. My ORM of choice is LLBLGen Pro, a mature and powerful product. There are many others, and in the .Net sphere NHibernate is probably the most popular. The problem I had is due to the licencing of the MySql data provider used by LLBLGen. I may have gotten this wrong, but at the time I wrote version 1 of these apps it looked like the problems were, if not insurmountable, at least difficult to overcome. So I wrote my own data access layer using datareaders and, in some cases, datasets. I wasn’t happy with the result, but it was a very small application and it worked. As with most small applications it has grown and I decided that I wanted a better data access layer. I didn’t feel that I had was robust enough and I wasn’t happy with the code. And I certainly wasn’t happy with the datasets as the program grew.
What to do?
Microsoft hs brought out two relatively new data access technologies. The oldest, and it has been around for a few years is LINQ – Language Integrated Queries. I really like LINQ, and combined with lambda expressions it gives you a very concise way to query collections. And along with LINQ came LinqToSql, the ability to use LINQ against a Sql database. You are now able to write something very similar to Sql queries in code, as opposed to a string expression. LinqToSql works with a number of different databases provided you only want to read the data. If you want to do updates or inserts then it will only work with Microsoft SqlServer. From what I have read there are no technical reasons for this, so I assume that it was a marketing decision.
More recently Microsoft has released Entity Framework. This has been described by Microsoft as much more than an ORM. My experience is a little different. It seems to me to be very much less than what we would expect in an ORM. Object Relational Mappers have been around for years now. They have been popular in many other platforms – Java,f or example has had Hibernate since 2001, I think. Other languages have used them since the early 1990′s. They aren’t a new phenomenon. If Microsoft had introduced Entity Framework in the early days of .NET, say when .Net 1.1 was all we had, then I think we could put up with what they have given us. But it is no longer 2004. The .Net world has moved on and in 2009 Entity Framework just isn’t good enough.
And it isn’t as if Microsoft cannot product good products. The CLR is a pretty good framework. Visual Studio is a good environment to work in, and VS 2010 looks like it will be very nice. WPF and Silverlight are not perfect but pretty good and getting better. C# is an enjoyable language to program in. The Java crowd will deride me for saying all this. But I believe that C# has overtaken Java and it is continuing to evolve. Microsoft has undoubtedly got some talented people. But they missed the boat with Entity Framework.
What’s wrong with it? First off, it is very slow. Over the past few years performance has become less of an issue in the sort of business applications that I write. Computers are fast. Most have multiple cores and memory to spare. In most of the applications I write the biggest impact on performance is data access. You have to go to the database, get it to its own crunching and return some data. Entity Framework uses reflection to create the objects. The first time you send a database call is the worst. After that it is is still slow, but getting closer to acceptable. LLBLGen, on the other hand, creates the classes as part of a data access project. The runtime experience is very good. It is no differenct from creating any other object once you have the data. The difference is that with a decent ORM your performance is once again determined by your database.
The second problem with Entity Framework is that it is very difficult to use. Julia Lerman has written a book about Entity Framework and is in the process of writing an update. She has an article, 8 Entity Framework Gotchas that is worth a read. Entity Framework is just not very intuitive.
The final problem I want to mention is the designer itself. Entity Framework runs inside of Visual Studio. You create an Entity Data Model item within a project. You are then taken to a wizard and from there you can create a model from your database. All well and good. But every table you need is placed on a visual canvas. The small application I was building only had eight tables, but that was more than enough to look at on one screen. What is it like when you have 50 tables which is not a large number. I recently did a project which had to query a database containing 24 tables and 27 views. And this was a relatively small application. I wouild have hated to look at my model in the Entity Framework designer, it would have been virtually impossible.
There is a new version of Entity Framework coming out soon. Perhaps it will ship with VS 2010. And I am prepared to give the new version anothe go. But at the moment it is practically unusable.