It is possible, but I don't think it's ideal, as you'll end up with a class hierarchy of unrelated classes. Putting classes into a hierarchy just because they share some fields isn't great. Better solutions would be to create a CompositeUserType for the userName and dateChanged columns, or to go with a variation on implicit polymorphism, or both.
The composite user type thing is well documented, you can read up on it in the hibernate ref docs, and presumably in the NHibernate ref docs too.
The implicit polymorphism thing works well in conjunction with the composite user type. Essentially, you create your superclass containing the composite class, and all your classes extend this, but you don't map the superclass. You map the normal classes in the normal way, specifying the composite user type in each mapping. Because each C# class extends the superclass, you never need to worry about writing extra code; and because the mappings don't extend a fake superclass, you don't risk confusing whoever will be maintaining your code in a few years' time.
_________________ Code tags are your friend. Know them and use them.
|