This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
We have 2 lightspeed models, in 2 different assemblies with 2 different namespaces. One in namespace X.Framework and one in Y.Project. The framework deals with pages/navigation the project namespace with the project specific domain. Sometimes however we would like to be able to replace the Page Entity in the framework with a subclassed one specified in the framework project. Adding metadata on entities or linking it to entities in the Y.Project namespace. Any thoughts on how to accomplish this, or find a viable workaround ?
|
|
|
Unfortunately this is not possible in general at the moment. LightSpeed basically expects the model to be within a single assembly, and this constraint is particularly important in inheritance hierarchies (as it attempts to build a 'flattened' view of the hierarchy for mapping to the database). Associations across assemblies are particularly problematic because associations are always bidirectional so this would result in a circular dependency (this isn't an issue if the association is to a base class in the same assembly, and you then add a discriminated subclass in the other assembly -- but then you run into the cross-assembly inheritance issue). However, if you have only two assemblies, then I think you will be able to get it to work, though it will be a bit kludgy and brittle. I think there are two major limitations/issues: 1. Associations must always be intra-assembly. For example, if you have Framework.Company, Framework.Person and Project.Employee (derived from Framework.Person), then the association must be between Company and Person, not between Company and Employee. But you will be able to load Employees polymorphically through single table inheritance. 2. At runtime, in each AppDomain, you must touch a derived class from the Y assembly before you touch any class from the X assembly. For example, create a dummy Employee and add it to a dummy unit of work, before you ever mention a Company. (LightSpeed can cross assemblies from derived to base while flattening, but not the other way, because derived types have info about their base types but not vice versa). Some trial and error may be needed but we will be happy to support you with this. Note also that you will almost certainly not be able to use designer sync or generated migrations, though of course you will still be able to hand-code migrations. |
|