Oct
14
Written by:
Gama Martinez
10/14/2010 10:40 AM
With a number of O/RM mappers out there, it is important to periodically look to see what is available and compare it to what you have. Innovations can happen at any time and you never know when the underdog will stumble across some new idea that will suddenly turn them into an industry leader. So we are left needing to consider why we should use something like LLBLGen 3.0 as opposed to Entity Framework 4.0, which comes as a part of Visual Studio 2010. As someone who had only used ADO.NET before I used any sort of O/RM, my perspective comes with less bias, and admittedly less experience, than the opinions of those who have been using LLBL or Entity Framework for years. As such, it may be especially useful if you are trying to determine which product you want to use when you have experience with neither.
At first glance, Microsoft Entity Framework looks to be superior to LLBL. It is easier to understand and implement. In general, it is far more intuitive. Going through Microsoft’s easy tutorial will leave you with a fully functional project with source code that is easy to understand and can serve as an excellent foundation to learn more advanced concepts. The extra files that it adds become part the project itself as opposed to creating a whole new project within the solution. LLBL, on the other hand, seems cumbersome by comparison. As implied above, it creates a new project. It creates three files for every table and one for every view. Updating the database, while not overly complex, is more complex than it needs to be. The learning curve of LLBL is definitely steeper.
From a bird’s eye view, Entity Framework has the upper hand, but such things don’t always stand up to scrutiny. In order to get a better grasp on the differences, I decided to rewrite a project that was already using LLBL to run on Entity Framework. I still remember the confusion I encountered learning about LLBL so I thought changing this program from running on something complex to running on something simple should be relatively easy.
Before I used any O/RM, I frequently wrote my queries directly into the source code. The purpose of O/RMs is to simplify things so that this isn’t necessary, but I really didn’t see much a difference when using Entity Framework. For example, I ran into a situation where I needed to build a query with a variable number of parameters. Entity Framework seems to be lacking this functionality, and as a result, I had to build the query as a string. If the number of parameters was static and only their values changed, then Entity Framework would’ve been able to handle it. However the dynamic list seemed beyond it’s built in capabilities. Don’t get me wrong, it simplifies your basic SELECT and UPDATE statements and you don’t have to worry about opening and closing connections to the database, but those things were never overly complicated. The impression I got from this is that Entity Framework simplifies the simple things while leaving the complex ones alone. LLBL, on the other hand, is built to handle these types of queries. There is a mechanism built into the software that allows you to dynamically add parameters as opposed to just setting their values.
Both systems have their ups and downs when it comes to updating the data model. As expected, updating is easier in Entity Framework. It’s a simple matter of right clicking and selecting “Update Model from Database.” LLBL is more complicated, but not especially so. As stated earlier, LLBL creates multiple files per table and you have to make sure that those files are handled correctly. Since an LLBL project is basically a self contained module within the larger .NET project, once the LLBL has updated the data model, additional steps are needed to populate the changes into .NET.
When it comes to actually updating the database, Entity Framework has the edge. Because controls are linked to the database, once the user has made changes and saves the data, only a single line of code is required to commit all the changes to the database. LLBL, on the other hand, necessitates copying the values of the controls into an intermediary entity collection, loading this collection into a transaction, committing the transaction and, then saving the entity collection. If there are several fields containing data that needs to be updated, this can become cumbersome. Naturally, it is important not to simplify to the point of losing the ability to customize, and Entity Framework does not slack when it comes to this. You can create several datasets to represent all the fields that you will want to update at once, essentially allowing you to group your controls. When you need to update there is just one simple statement per dataset. As a result, compartmentalizing your data becomes slightly more complicated but is still much simpler than LLBL.
One of LLBL’s greatest advantages is its use of a typed list. A typed list basically allows you to build an intermediate table between the database and your application. This is similar functionality to an SQL temporary table except that it is directly accessible by the application. This allows you to customize the appearance of your data in ways that would otherwise become much more complex.
In many ways, Entity Framework is much easier to use than LLBL. However, as is often the case, this simplicity comes at the cost of power. Both LLBL and Entity Framework have the ability to simplify the access and manipulation of data, but where they differ is in how far they go. Entity Framework focuses on a point-and-click interface that ultimately falls short when dealing with the more complicated database interactions that are inevitably a part of larger projects. LLBL has a much steeper learning curve, but in reality, this is a concession to the fact that certain things can only be simplified so far. In order to have something that is fully customizable, you need multiple steps because, at any point, you might have to change those steps to do something other than the default. This necessitates a certain complexity. In simpler projects, Entity Framework has the definite edge, but if simpler projects were all there were, then there wouldn’t be much of a need for an O/RM in the first place. For anything of at least moderate complexity, LLBL would be a better choice.
Copyright ©2010 Gama Martinez