Jonas Helming, Maximilian Koegel and Philip Langer co-lead EclipseSource. They work as consultants and software engineers for building web-based and desktop-based tools. …
EMF Dos and Don´ts #2
EMF is a very powerful framework and with power comes…responsibility. You can achieve great things with a minimum of effort using EMF, but if something goes wrong, you can also spend hours trying to find out why. This blog post is part of a series on things you should do and things you should not do when using EMF. You can use the link to the series pilot to navigate to the start and the next link below to navigate to the next blog once it is published.
EMF Don`ts #2: Change generated setter and getters in the model plugin
You might feel the temptation to change generated code in the model plugin. More often than not, this is a bad idea. Changing a generated getter or setter will influence the behavior not only of your application but also for all EMF-based functionality including frameworks such as CDO or EMFStore.
EMF enables reflective access to fields of an entity object (read EObject) via EObject.eGet() and EObject.eSet(). This is used, for example, by XMLResources to serialize and de-serialize EObjects into/from XML. Consider de-serializing an EObject: XMLResource will attempt to reflectively create the respective EObject with its factory and then continue to set all attributes and references according to the XML via EObject.eSet(). If you implement code into your EObject´s setter that will set other attributes or references in turn, this will be triggered during de-serialization, which is not what you intended most probably. Implementing this code could lead to overwriting values in your EObject that have already been set by XMLResource, which means you could change your data by simply saving and re-loading!
A good place to implement additional behavior - other than just setting or getting an attribute or reference - is a controller object following the Model-View-Controller pattern. If you intend to ignore my advice or if you have good reasons to change a generated getter or setter, follow the advice in my next blog about how to extend the generated code.
Stay tuned for more Dos and Don´ts in my next blog!