Dmitri Maximov (Xtensive) wrote:

Hello David,

Here is brief comparison:

DO4 - pros:

• Advanced LINQ (support for large collections in IN, highly extendable translator)

• Automatic database schema upgrade routine & version-to-version migration pattern for developers

• Advanced domain modeling features (persistent interfaces, generics, even open ones)

• Better performance on reads and writes (there are batching, future queries, prefetch, etc.)

• Integrated Full-text support

• Lightning-fast technical support

EF4 - cons:

• Issues with large models (well-known case, try to use e.g. 200+ type model; on 600+ type model designer needs >5 minutes for almost any action, e.g. opening it)

• No support for enums

• Less adopted for inheritance (e.g. there is a single query root for the whole hierarchy, so you must write dataContext.Root.OfType<t>()...).

• Free framework, but many of providers are commercial (e.g. for Oracle there are no other options at all).

Alex (Xtensive) wrote:

Few more diffs:

1) DO4 is designed to handle server-side operations well - it provides really transparent view on data. EF does not - the part of database you access must always reside in memory; rollbacks and attempts to access the same data don't lead to any refreshes there. Some consequences:

• It's ok when you use e.g. nested transactions with rollbacks in DO4. Refreshes are automatic here.

• You can sequentially process very large object set in DO4 in a single Transaction & Session, but the same is difficult with EF. Earlier we had a nice test: creating & enumerating 5M entities in a single transaction. DO4 pass it even with memory provider. EF fails on it - so it needs more RAM to track changes then our memory provider of DO4 to store the same data indexed. In case with regular provider DO could process generally any number of entities: by default it keeps in RAM just states of the entities you're really using, although this is configurable.

So DO4's model is more suitable for implementing complex server-side logic. EF's model works better if operations executed from UI are purely CRUD operations - i.e. WCF Data Services-like RESTful APIs are fully sufficient for you. Let's illustrate this on examples:

• EF is a good choice for blogging and Twitter-like applications

• If you're building something complex - e.g. document management solution with complex workflows & logic or an application like MEScontrol, DO4 might be a better choice.

Or, shorter, if you expect there will be 50+ persistent types + some complex logic, DO4 might be a better choice. Btw, just think about maintaining database schema for an application with e.g. 500 persistent types.

2) DO4 offers high-level abstractions by default:

• EF provides simple API by default; making it adopted to real-life conditions requires additional efforts (INotifyXxx, lazy loading, smart collections, etc.). So close-to-POCO behavior is default here, everything beyond this requires efforts (in many cases - deep knowledge of the framework).

• DO4 provides relatively complex API by default (that's why we require you to inherit your classes from our base Entity, Structure and EntitySet<t>), but allows to get simplified views on the same data via O2O mapping and support of POCO/DTO entities materialization in LINQ. WCF Data Services support is one more option you have here. So we're initially focused on more complex cases, and this implies you should spend more time on studying the default logic we provide. But we think it's reasonable, since most likely you'll anyway need this in development.

3) DO4 is designed for model-first & code-first development; legacy mode is relatively new here. On contrary, EF provides good support for legacy databases, model-first mode isn't the primary option here.

So if you're developing a new application, DO4 might be more attractive. Take a look at our tests: there is no need to care about database schema and so on. This is really convenient: modify & refactory you classes, start the application - voila! Everything works.

DO might also be a good choice if legacy database has lots of tables (and it's ok to have restrictions DomainUpgradeMode.Legacy has). The next section describes, why.

4) DO4 works very well with large models. Mainly, because it doesn't require you to use a designer (you can use built-in VS.NET class designer, but currently we don't provide any DO4-specific extensions for it).

As far as I can judge, many of ORM tools providing class designer integrated into VS.NET are simply not adopted for this case. E.g. currently both EF and L2S might require up to 10 minutes to just open a database diagram with 500+ tables. An attempt to navigate there makes VS.NET to hang for minutes as well. It seems that's mainly related to really complex nature & model provided by VS.NET DSL Tools - most of class diagram editors for VS.NET are based on this toolset.

I'm not sure about commercial tools here, such as Lightspeed - if you consider them and expect your project will b large, it's better to contact the vendor and ask about the largest model(s) used by their customers.

5) DO4 provider model is designed to support indexing engines as well. And although currently there is just in-memory provider acting more as "demo", in future we will deliver few more of them. So likely, in future DO4 will be a better choice for integration into relatively small applications, since you won't need anythign additional.

6) POCO support. Currently DO4 doesn't support POCO, although we're seriosuly thinking about providing support for it in future (~= transparent O2O mapping between our own and POCO entities). Let's see.

7) EF is Microsoft product with all the consequences. In particular:

• Lots of info around, including books

• Slow bugfixes, although most bugs there must be known & desribed

• Slow support

• Big community

• Free.

The advantages we offer here include:

• Fast support.

• Fast bugfixes. The product is very stable in comparison to many others (few recent examples I remember: http://goo.gl/ROtl and http://goo.gl/3YC1 ), but obviously, there are still some bugs, and getting them fixed fast is important.

• Nightly builds + "live" stable branch: paid customers are able to access latest fixes instantly. The actual stability is known, since there is CI server running 2.7K unit tests on all the confugurations (about 30) each night.

• Openess of team members. E.g. during last months I have a set of Skype\GTalk chats with out custmers each day. AFAIK, nearly the same is correct for Dmitry Maximov.

• Responsiveness to customer needs. If we feel something is really important for our paid customers, we prioritize this.

• Much more frequent updates. Currently we target on one major update per 3 months.