| Hello,
I'm after some general modelling advice. I've been using inheritance for years to model app-specific versions of a framework-level Person (user) entity. This works well enough, though it presents the same small headaches time after time for each new application.
I also have a framework-level Organisation entity to model a user's organisation. I need to customise this for a new application, and I thought this time I would use composition instead of inheritance—I'll create a new FooOrganisation entity which has a to-one relationship to Organisation (without the inverse relationship), and then the additional attributes and/or relationships which are app-specific.
The application is still in development, but there's a demo deployment, and while I _can_ wipe the database, there are existing Organisation EOs in it, and it would be nice if I didn't have to. I'm using migrations, so I can perform any one-off fix-ups in a post-migration step.
So, do people model like this? Are there any pitfalls? What's the best way to ensure referential integrity, such that Organisation and FooOrganisation remain 1-1—'owns destination' and 'propagates primary key'? (Selecting those will require I scrap the DB and create the FooOrganisations first, won't it?) Would dynamically adding some properties to the model at runtime be a better option here if I just want to store, say, a few limited extra attributes on an entity?
|