Layer supertype. Supertype. Sounds pretty impressive, eh? A technique so puissant it needs not one but two pictures of Plush Ninja, that’s how earth-shakingly puissant it is? The sort of post where by the third paragraph your brain is asploding with all the category theory and a talking frog reveals the secret of monads while a psychedelic spaceman dances the rumba in your b**rd?
Sadly, no. What ‘layer supertype‘ means is simply ‘I want all my business entities to derive from my entity base class instead of directly from Entity<T>.’ (More generally, ‘layer supertype’ means ‘I want all my classes in a certain layer to derive from a particular base class.’ You could also have a layer supertype for your UI layer, where all your Web pages derive from MyWonderfulPageClass instead of directly from Page. But we’re only concerned with the entity layer here.) A layer supertype can be handy if you have a bunch of common services, interfaces or helper methods and want them to be available on all your entities.
To implement a layer supertype in the LightSpeed designer, you can set up a Defaults Policy which specifies a Base Class. The designer will apply this to all new entities you create.
To set up a Defaults Policy with a defaults base class:
Usually, you’ll create an entity in the designer to serve as your layer supertype. Even if the entity doesn’t define any fields and all the work happens in the partial class, it can still be handy to have the entity there to stop the designer worrying that you might have sneaked something in that could interfere with Update Database. However, if you’re worried about clutter on the diagram, you can hand-code the supertype entity. In this case, you’ll need to tell the designer about it by right-clicking the Model node and choosing Add New External Class Reference. Once you’ve done that, you can choose it in the Defaults Policy Base Class drop-down just as if it were a designer entity.
It’s important to realise that the Defaults Policy controls defaults for entity creation. If you’ve got existing entities that already inherited directly from Entity<T>, the Defaults Policy won’t change their base classes. And it won’t stop lollards and schismatics from changing the base class back to Entity<T> after creating the entity. LightSpeed doesn’t enforce your layer supertype; it just helps you to implement it.
And that’s all there is to it. If you want a default base class, LightSpeed can deliver it. Just be sure to call it a layer supertype at cocktail parties.
So back to the cupboard, Plush Ninja. Your time will come again.
You should join our newsletter! Sent monthly:
Aside from being much cleaner, does this differ in functionality versus creating an Entity marked “abstract” and then having other entities use that as a base class with concrete table inheritance?
Also, can you have multiple “default” entities? Or is the option Entity, MyNewEntity and then inheritance for everything after?
No. All it does is automate the act of setting the base class and specifying concrete table inheritance. The outcome is the same.
There is no option for multiple “default” base classes, because then, well, which one would be the default? *grin* (Of course your default base class could inherit from another intermediate type.)
Leave a Reply