Why should I use EMF?

Question

I've read some tutorials about EMF and I still wonder why I should use it.

Until now, I was generating my POJOs from XSD schema + JXC, or by hand.

As far as I understand EMF it can be useful to define some complex relationships between the classes (one-to-many, etc...). But is that all? Isn't it more complicated to generate the code with EMF? Doesn't it add some extra-dependencies?

Answer 1

In general terms one could say that using emf provides several benefits at runtime.

On a first stage you'll notice that the ecore classes (and the emf runtime) offer what you might need from your POJOs in your application. There's no further coding needed in a lot of areas whereas you would need to code a lot by hand when using plain POJOs:

• You get a full blown notification system (no PropertyChange coding any more). It even offers notifications for changes that occur further down in you instance-tree (attach listener to x, get notified of changes in y which is referenced by x).
• values are unsettable (actually a very common need: you need to know about 3 states of a value: it is set, it is set to null or it was not touched).
• bi-directional references: X references Y and vice-versa. Remove the reference to Y in X, the opposite reference is removed, too.
• XML, XMI (etc.) serialisation support out-of-the-box.
• lazy loading: you can partition your model and have certain parts loading lazyly only.
• etc.

Extensions to EMF even offer far more:

• EMF Query or EMF Path add advanced query capabilities to collect pojo instances for given criterias
• CDO allows you to code 3-tier applications without any further hand-coding. CDO adds Database persistency and remote notification (sessions, transactions, versioning, branching, etc.)
• Xtext adds serialization to custom DSLs (define your own serialization format/dialect)
• etc.

You could actually argue that EMF/Ecore offers a standard for POJO and a whole ecosystem grew around it that actually offers what you would code by hand in a classic approach.

To be honest, the downside of EMF is that you get tied to the Ecore runtime which is very fine if you code Eclipse based rich clients but may become an issue if you are on the server.

Answer 2

IF your only interest is generation of POJOs, then I agree that there are many alternatives out there to achive the same you can do with EMF.

However, Java generation was just the first application of EMF. Now there are a huge number of EMF-based Eclipse plug-ins that give your for free a lot of functionalities to manipulate (query, validate, transform,...) your EMF models.

See the Eclipse Modeling Project for a list of official Eclipse projects on EMF.

Also, take a look at Acceleo to see the flexibility of their template-based generation approach from EMF models (for Java, PHP,...).

Answer 3

Adding to what Jordi said EMF provides notification mechanism which unlike XML Beans for example, allows you to add listeners to model changes. So when changes occur in the model you get notified about this change.

I've successfully used EMF Query to search model using SQL-like syntax, and using OCL. EMF Validation is a great framework for validating your model based on what's defined in schema as well as introducing your own validation logic if it cannot be expressed in schema.

Answer 4

On high level EMF is an implementation of MOF standard for model-driven engineering or MDA. So, using EMF you get access from you generated Java code not to Java Objects, but to their Model too. Which if far more than just Java Reflection features.