ECO compared to Microsoft’s "Entity Data Model"

> [..] Yes ECO has potential. But:
>
>1) Does it lose any "umph" when EDM is released?

With EDM, you do mean something other than Enterprise Data Management as outlined on http://www.microsoft.com/sql/solutions/edm/overview.mspx and http://msdn2.microsoft.com/en-us/sql/aa336354.aspx?

I assume you are, as that seems to be more enhancements to SQL Server, which would be of potential value to ECO users as well (should they chose to deploy on Sql Server).

Next I ran into Electronic Document Management. Hmm. No, you probably didn't mean that either.

Continued to search and finally found Entity Data Model. Finally we're getting somewhere. Of all the 25^3 TLAs, what is their coverage? Do they really need to overload EDM so badly? :)

Anders took a brief look at it and commented on his blog.

A link to the overview document is here.

I personally think it's good we get someone to compare with. If you're the only one making a particular offer you're either years ahead of the competition or selling pre-bent already-rusty nails. The fact that other now try to do what we have been doing for almost a decade sort of eliminates the pre-bent nails option :)

EDM seems to offer a pain-relief to a lot of people. We will still stand very strong in comparison.

ECO is a model driven platform. It allows you to specify the logical layout of the business domain of your application using standard UML notation for class diagrams and state machines. OCL (again a UML standard) is used to define constraints on classes, synthesize data (something like calculated fields, but also used to derive associations - with full support for "virtual derivations" to be redefined in subclasses).

State machines allow you to specify triggers, guards and entry/exit actions using OCL and Eco Acion Language (EAL). EAL is more or less OCL but the constraint that it mustn't change any business state has been lifted. In other words you can write EAL statements to assign values, create instances or delete objects.

Persistence is done on a large number of backends, with shifting from say SQL Server to Oracle being as easy as dropping and connecting a component or two. ECO generates standard SQL is a SQL based backend is chosed. It is also possible to collect the business data from any number of a heterogenous set of backends thanks to the powerful OR mapping engine in ECO. Your customer objects can come from a SQLServer DB while your invoice objects are fetched from an Oracle DB. All that is transparent to the end user (but in all honesty requires the developer to set it up :) ).

Note that this backend agnostic model is also presentation layer agnostic. You can surface the UI in winforms, ASP.Net, wrap it in web services and we have plans to extend that list even further.

Coding on model level allows you to focus on delivering what the customer pays for - solving business problems. The code you need to write is more to the point and significantly shorter. The data you need is there when you need it thanks to the lazy evaluation in ECO. The consistency of your business layer is kept intact, including both ends of bi-directional associations. We have built-in support for undo/redo, transactions, evaluation, subscription, persistence, model inspection, synchronization between clients and more.

Furthermore, ECO doesn't preclude you from using other mean and lean technologies. Not to say that we hardwired interoperability with everything from cryptography algorithms over device drivers to enterprise phone books, but hey, you are all programmers. It's all software. No magic.

--Jesper
R&D Manager ECO