Can I say, I’m actually a little disappointed in EntityFramework right now. We were moving to more of a model based solution with the second version of our software, but found these pitfalls:

1. In all but the simplest Admin forms stored procedures will be necessary. For example, you will want to update against a table – but run checks against a balance, or update a ParentID, or modify related information – you’ll have to spill across multiple entities. The simplest way I know of doing this without a lot of wasted code is db-side sprocs.
2. EF works TERRIFIC when you’re binding directly to a table. But as soon as you have to use sprocs there’s a TON of manual coding and clicks that has to happen. This means the same or more amount of work than in old-school DAL layers.

For example, look at this EF sproc mapping:

Say it with me – Eeeeessshhhhh. Having done a few dozen of these mappings so far I can say it’s a painful process and as fraught with peril as any DAL layer. And, since it’s graphically based and not a class, I frankly don’t trust it as much when it comes to making changes. EF does a good job of prepopulating many of these, but not always – especially if the table name and the field name are the same, or if the casing is slightly off (Id versus ID for example). I may end up sighing, throwing up my hands, and rolling back to a SqlDataSource instead.

Long story short – I would love to blame our ever-increasing list of functionality but specs are specs, and I don’t think things like soft-delete or cascading changes are unique to this application/working environment. And, I’m looking back on the road we chose not to take – BOWA (Breeze-OData-WebAPI-AngularJS) and wishing we had spent a few more weeks on architecture and a firm set of guidelines/standards. It would have paid off handsomely when it came to maintenance and durability for this app.