Monday, March 26, 2012

What every Eclipse Developer should know about EMF

A good, albeit at times a little rushed, introduction to EMF, the Eclipse Modeling Framework. Concentrated on ECore through generated Java. Other modeling tools can do all kinds of transformations.

Some highlights:
  • Some history - 10 years old, IBM MOF was thought to be too complicated so a subset was spawned as EMF.
  • Generates Java classes and adapters.
  • Can be used when data is to be stored or model displayed/modified in a UI, i.e. data binding.
  • Has a small development cost with large return, i.e. a few lines of ECore model can generate many times that number in lines of Java code (assuming you know how to use it).
  • Tutorial example was a modeled bowling league, players, tournaments and games. Each was modeled and graphed to show relationships via UML.
  • ECore model: EPackage, EClass, EAttriibute, EReference
  • EDapt - facilitates EMF data migration, i.e. migrate existing data to accommodate a changed ECore model.
  • Never modify generated factory classes! Always modify the ECore model and regenerate the Java classes.
  • Rich API to use model elements with or without instances, e.g.
    • BowlingFactory.eINSTANCE.createMatchup()
    • assertEquals(matchup, game.eContainer());
    • EMF utilities: EcoreUtil#getRoot, #copy, etc
  • All modeled objects are contained in some container, otherwise removed. A modeled instance can be queried for its container even though it may not have a getter for it.
  • ECore Commands allow programmatic changing of the model instances but use an undo/redo stack. Useful for test cases.
  • http://eclipsesource.com/emftutorial will soon have an updated version of the tutorial.
  • In my opinion, this could work very well for the right problem but could also become another layer to maintain and train up on if overused.
  • Eclipse 4 will include an EMF-modeled Workbench which we probably should get to know.

No comments:

Post a Comment