My team building a monitoring administration front-end WPF application. of course, we have a lot of data stored in a database and we need to show the end-user a view from this data. I’ve been asked to choose our DAL and Entity technology and design the business-objects.
My first decision was to use LINQ and anonymous-type in the front end. this is mainly because the application is for monitoring only and there’s no updates or insert operations.
The next step was the data layer and the Entity technology. I don’t like writing XML by hand (who does?) and I really prefer drugging shapes from the visual studio tool box and (hopefully) auto generate code behind. so NHibernat is out of the game for me. Now, I needed to choose between LINQ to SQL and ADO.NET Entity framework which both comes with a visual studio 2008 designer.
My first attempt was EF because it suppose to replace LINQ to SQL (is it just so?)
Like everyone, I saw EF demos working when executing INSTER/UPDATE/DELETE stored procedures mapping exactly to a table entity, but in my case, I need a custom entity based on a table view and stored-procedure result.
I’ve fight with EF (on VS2008) for almost all day long and it appears that EF (currently) doesn't supports out-of-the-box entity generation from SP and Views. I did find workarounds but I don’t consider workaround as a reliable solution.
Honestly, I find that really odd…
Every production real-world environment works with SP and view, so I just can’t understand what was the point of releasing a framework that missing basic requirements for a production use…
For the guys in Redmond, I just have to say that there are some companies that taking your produces seriously, so please, stop with those semi-CTP frameworks. If you are releasing a product, try give another thought of productivity. Sorry to say but, currently, EF is great for ORM demos and presentations but not for real-world systems.
Currently, I’ll use LINQ to SQL.
