No I have not suddenly stopped blogging, I am rather busy with some matters at work that need my dedicated attention and caused me to have a few migraines and nightmares. But I have a plan! In the next 2 weeks things should settle a bit and I have a few unfinished entries in the pipeline.

Here is what you can look for in the months to come:

• ADO.NET Entity Framework and Linq to Entities, this will most probably be a multi-part series of entries.
• More on Project Banana.
• More on optimising ASP.NET generated HTML and maybe a bit on ASP.NET MVC, this will also most probably be a multi-part series of entries.
• In April, May or June some travel and photos, I will try for a daily “live” post now that I have a 3G Modem.
• A couple of movie reviews, I want to make this a weekly feature in the future.
• A guide to making Site Management System, if I have the time.
• Some photography entries, if I have the time.
• More rants and complains and maybe politics and economics in South Africa.

Additionally, I hope being able to post about Gizmo (currently in version 11b) seen here below.

I you would like to see something specific, leave me a comment.

This is a follow up article from Legacy data with Entity Framework.

One can only love Linq, however this is not true about the ADO.NET Entity Framework and therefore Linq to Entities. With the announcement of the abolishment of Linq to SQL I would of thought that EF would be a really good replacement. I now can tell you that Microsoft still has a lot to do to get it right.

EF feels clumsy, it does not react as expected. For example, I create an entity from table “tbl_Customers” and name the entity “Customers” I expect all references to that entity to be “Customers” but this is not the case. I now create an Entity called “Regions” from table “tbl_Regions” and do a reference from RegionID in Region to RegionID in Customers. I then expect to be able to call Customers in Regions as follows Regions.Cutomers simple. However, if the property “” is not set as well as the name I have to the call as follows Regions.tbl_Customers. Why should I have to name anything more then the entity name? If that is not clumsy I really don’t know what is.

Furthermore, creating inherited entities is next to impossible, the fact is that you have to use NULLS in your table to differentiate between entities, using legacy tables this was not an option and even when you manage there is a lot of other issues. Let me elaborate

I just have and I was surprised on the first page I appear a cool 5 times, even though my blogs image representation needs updating.

I should call this post “Learning the practical side of ADO.NET Entity Framework” since it’s the first time I use it in a real world application. I generally do not like to use new technologies for the sake of it. However, this seemed to be the right time and opportunity to learn ADO.NET Entity Framework in a real world situation. A quick fix to a complex problem, I needed to “plug-in” a new web application into a legacy database, the catch was that I would have to change the database latter and this new database would have a new schema. ADO.NET Entity Framework would allow me to create my new schema with the old one and map it to the new database latter. Great to avoid to do the work twice…

The first thing I found out with the ADO.NET Entity Framework is that it is fiddly at best. I thought it was going to be the easiest solution and to be entirely honest had I coded my DAL myself as I used to, I’d be finished!

Right, I am not entirely truthful, I am using a database with garbage in it. But still, if I have to use NULL’s to differentiate between object types it becomes a problem, I do not believe in NULL values in a database.

The situation is as follows, I have a legacy table that contains product categories and actual products, the table’s data is really dirty. So I want to create 2 Entity Objects one called “Categories” and another called “Products” and let the ADO.NET Entity Framework do the differentiation using a column with a true or false, easy! well it does not work! I kept getting a mapping error in Visual Studio 2008. After some research on the net I found out, to my dismay, that differentiators can only use NULL’s. So, the product category record must have a NULL value in some arbitrary field to be recognised as a category object by the ADO.NET Entity Framework, how ridiculous!

So, I cleaned the data and set a field to NULL, set the clean renamed CategoriesnProducts object to Abstract = True. Next, I created 2 objects Categories and Products both inheriting from CategoriesnProducts then mapped my legacy table to those new entities. At which time I found that all the fields in the legacy table where flagged Not NULL, so I took those flags off, even though it meant changing the database, I knew that it would not affect any of the other applications. Refreshed the schema. Sort out the new entities mappings and voila… I had a successful, error free build.

On the bright side, a many-to-many relationship is a breathe in the ADO.NET Entity. It maps it all out and abstracts it completely as seen in the relationship between CategoriesnProducts and LegalDocuments.

Next Linq-to-Entities.

In a hosted environment the choice of databases is obvious, either Microsoft SQL or MySQL. However, there are other possibilities to store data such as XML, Microsoft Access and why exclude SQL Lite. All of these should work fine in a shared host environment which is my target. In fact for testing purposed I have hosting at GoDaddy.com, if it does not work there it’s back to the drawing board. The URL will be www.projectbanana.net, not that there is anything there yet.

So we are spoiled for choice in the database realm, I will pick the following:

• Microsoft SQL 2005, 2008 and Express even tough i have not heard of a hosting company using express it help during development.
• MySQL 4 and 5
• SQL Lite

Initially, I will only focus on Microsoft SQL 2005 Express keeping in mind the other two. The next question becomes how to access the databases? The fact is that I do not want to have to write different providers for different databases. The possible and first choice is an ORM, luckily for us Microsoft gives us the ADO.NET Entity Framework, however GoDaddy does not run version 3.5 SP1 yet. So maybe an alternative would be more viable, the ALT.NET community gives us NHibernate for .NET but NHibernate is not Linq enabled yet. For that matter, one could say that there are some issues with the ADO.NET Entity Framework too, the .NET connector for MySQL is not EF ready yet either and all there is to reassure us that it will happen is this entry  by Reggie Burnett in May 2008 and then this one here. But the pressure is building and I expect it to come soon enough. The bottom line is that I cannot wait for either of these to happen. So ADO.NET Entity Framework it will be and if I shoot my self in the foot, I will have to rewrite the entire Data Access Layer. I wander about Subsonic though, they support SQL Server 2000 or 2005, MySQL, or Oracle with SQLLite, SQLCE, and PostGres coming soon according to their page not to mention Linq in the soon to come version 3. So I may have been hasty on my decision, watch for an update.

The good news is that SQL Lite’s ADO.NET provider supports ADO.NET Entity Framework, one less worry. What about other databases such as Oracle, Sybase and others? They do not seem too concerned about EF and they will tell you that there are 3rd party ADO.NET providers available. As for ORMs here is a list I found.

Next a short discussion on standards, components and patterns.