| In any case I generally avoid using derived attributes altogether and use custom business logic instead for the following reasons documented in the EOModeler user's guild:
----------------------------------------------------------------------------------------------------- Derived attributes are effectively read-only since there is no place to write them back to. You could get the value of a derived attribute and write it back to another column but that requires another attribute. And if you need to store the value of a derived attribute, it’s usually much better to perform the derivation in business logic rather than at the attribute level. (Alternatively, you could use custom read and write formats to accomplish this. See “Read Format and Write Format”). By deriving attributes at the business-logic level, you write the code in Java, you avoid writing database-specific SQL, and you get the full benefits of enterprise objects. One of the most important benefits is the internal update notifications that enterprise objects send and receive. In the previous example, if you change an employee’s monthly salary, the derived attribute that calculates the annual salary is then incorrect. And since the attribute is derived, its value as it exists in the enterprise object is immutable. Unless the object is flushed from the access layer’s snapshot and refreshed, the derived attribute is stale and inaccurate. Derived attributes can be useful but should probably be reserved for read-only applications and can usually be replaced by values derived in business logic. Also, because derived attributes don’t directly map to anything in the database, they cannot be used for locking or as primary keys. ----------------------------------------------------------------------------------------------------- |