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?

Conundrum: shortBet and Rally planning

The Background
As many of you know I'm working on a new project, shortBet, which is an MMO credibility engine (still working out exactly what that means, but it sure does sound cool). With my partner on the project, Jamie, we've gradually shaped many of the architecture and design choices.

The project has been moving forward quite nicely in the current nascent stages. One of the conclusions we both agreed upon without much discussion was use of agile development methods. These methods have served us well in our day jobs so it seemed natural to put them to work for us on the construction of shortBet.

The Issue
Writing actual application code is imminent.

Well the time has come, and I'm sitting down as the customer to put in some stories for the first iteration. We've found an excellent (but closed source) free resource, Community Edition of the Rally Software Development. The Community Edition has essentially every feature any small team would need to implement planning with agile methods. However, before I go down the path of using Rally planning, I wanted to think aloud about the matter.

I'm coming to some stark realizations about the limitations of agile methods in our circumstances as this project moves forward. First off, let me stipulate that I think agile methods are great. I think planning software tools are essential for these methods. I think that Rally is very suitable planning software tool. However, I'm concerned that agile methods - specifically the planning methods - will fail us because:

• we don't have a genuine customer
• we don't have a genuine project manager
• we don't have genuine quality control testers
• we have an ultra small team of developers (and part-timers at that!)
• there is no genuine external pressure of time
• there is no genuine external pressure of money

Will the both of us switching customer, project manager, developer, investor and tester hats be feasible to pull off implementing the agile methods? The agile methods, in my mind, are about bringing these sorts of genuine people in a process cohesively, managing each roles' inherit point of view on a project's successful progression. Using the agile methods to artificially distill these roles out of a small (part-time) team doesn't seem philosophically sound.

Agile methods for planning do have a certain amount of bureaucratic overhead that though valuable and essential for the sanity of most development projects, may prove to be too costly to the limited resources involved in the project. What I fear is putting time towards making the agile methods work as if they were the ends and not the means.

The Alternatives
What I want to do, when I finally actually sit down to write the stories is just this:

• Write a sentence or two on what feature I want to see
• Assign it to a one of us

I don't really care what order the stories get done at this point and for the foreseeable future. I specifically don't care about estimates at this time. With our herky-jerky schedules, estimates no matter how accurate really have no meaning when the available pool of developer time to throw at stories is forever unknown.

Also, while the story is being worked by the developer, I want the planning software to be a centralized and historical place to document

• what aspects of the Entity Framework and MVC were used and modified to fulfill the story, or
• why the story will not be done, or
• reassigning to another developer

The question I'm flat out asking myself right now is this: Is the Google Code Issues interface a suitable alternative for a small part-time team than the full blown Rally planning interface for our team's needs? It's a limited interface, but is that limited nature a good thing?

.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.