Strike Two Entity Framework

This weekend will be my last try with trying to do something limited with the Entity Framework (EF) that is both reproducible and maintainable.

Working with the EF means a dependency on an Entity Data Model (EDM). No matter how nifty the EDM visual tool is, it seems to fall apart during evolutions of change in the underlying physical database schema during its incessant and overkill "updates" against said schema.

Posts like this from the ADO.NET Team give me the distinct impression that using the EF is going to be, over the long run, a heavy dose XML editing to get it to work productively. Honestly, I'm not interested in coding XML files in the least, which seems to be a trend in lots of areas of software frameworks these days, not just the EF.

As I try to apply the EF towards a practical purpose, I realize (again, for the umpteenth million time) why I have historically embraced the pattern of segregating the physical database schema and application code.

The only reason I haven't already abandoned the EF is because I'm keen to push myself to try something new. By Monday the proof will be in the pudding, or the pudding will be in the trash along with all the other ORM-like clap-trap I've previously suffered through.

Hmmmmm

Even though I've soured almost entirely on the .NET Entity Framework as a comprehensive design and application component - I still see it useful as a highly focused and limited tool.

Eliminating the unworkable process of generating an application's all-inclusive entity model, has seemed to be useful so far. Although, I'm still stuck in SQL Server World with the EF. Or am I?

.NET 3.5 (SP1 Beta) Entity Framework Test Drive

I'm giving the Entity Framework (EF) a test drive on the shortBet project. My primary reason for giving it a go was centered around the fact that I work primarily with Oracle database server on the backend and LINQ to SQL (L2S) is not a good fit for me. shortBet will be using SQL Server, so it serves as an excellent platform for this test drive.

Despite LINQ's greatness, I haven't been all that interested in L2S which has several nasty weaknesses. First, typical LINQ coding elegance falls down on its face when faced with joining more than a few queryables that are closely bound to relational views and tables. Second it generates SQL command text automagically, and I'm not intrinsically happy with that. Finally, and most significantly, use of L2S is bound to the SQL Server platform for the forseeable future.

The EF is an interesting tidbit I had heard was a better deal than the L2S way from a variety of .NET and Oracle resources I trust for leading edge information. After my test drive so far, my assertion is that it is and it isn't a better deal than L2S. It is, because queryables in the EF have a greater potential for expressing complexity and thus more elegant LINQ statements than using L2S queryables. It is, because the tools for expressing Entity Data Models (EDM) are fairly slick and effective. It isn't, because as far as I can fathom from my little dip in the pool, EF is utterly dependent upon L2S - unless you want to write your own custom Data Access Layer, which eliminating is one of the pillars of the EF. By using the EF, at best I'm out of the logical fire, but I'm still in the physical frying pan. It isn't, because even though I have a highly functional relational model for my Shortbet application - I can't seem to see how I would effectively express it with an EDM.

Part of that last failing is clearly because I'm a relational guy, and I'm not very good at OOP modeling. Partly it's because I believe (in my heart of hearts) that entity modeling is simply inferior.

So, at this point - although I'm still continuing with the EF test drive (thankfully I have some help) - I'm of the mindset right now that rich and meaningful entities are great - but a unified model of more than a child-sized handful of them is an irrational endeavor.

And a Wino Shall Lead Them

Not just begging off your spare change anymore...

Everyone knows what a wino is. We've all seen Wimpy after he gets his cheeseburger loan. Flush with cash, he heads straight for the quickest corner Mom and Pop and takes care of business.

I can't completely empathize with the wino, because I'm predominantly a beer-drinking fellow. However the term wino is still fun and useful. Today, I've hijacked it to name my latest project. Every information technology project simply must have a catchy acronym; mine is WINO. It's a redux of LAMP used by the overzealous open source community. The acronym goes: Windows (instead of Linux), IIS (instead of Apache), .NET (instead of PHP) and Oracle (instead of MySQL).

Sometimes I think I'm the only WINO on planet Earth. Microsofties (lovers of .NET) tend to hate Oracle Database Server for all its power and stability in favor of the drivel that is SQL Server. Oracle clergy tends to view Microsoft-anything as heresy. I'm somewhere in the ether between these worlds and I'm tired of being alone. I am out to recruit.

WINOs can now unite under my project banner and obtain sage advice, peer validation and lively source code that burns the bush brightly enough to know that their way is the righteous in the kingdom of software bundles.

Link: WINO Project