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
|
Is it possible to have one model with different entities defined in different assemblies. For example. Say I have a model named
Now later down the track, I want to extend this model by adding an address for the User entity. So I create a new project named UserAddress which references the
In that entity I want the, UserID and Name to be inherited from the |
|
|
Nevermind, after thinking it through a bit this wouldn't work for what I am trying to achieve. Instead I am going to split each extension into a different table like:
and
|
|
|
What is the best way to handle cross project one-to-one associations. With the above example what I can do is add the code below to make UserAddress associate with User.
The only problem is making User associate with UserAddress. Why this is a problem is because the code to associate them needs to be in the same project as the UserAddress. And I can't do
Since partial classes need to be in the same project. Below is some code which does work with getting an User associate with User Address, but it isn't a very elegant solution and requires a UnitOfWork to be passed to the extension function.
So next I tried the code below:
However it doesn't seem like public readonly EntityHolder Any suggestions? |
|
|
This is the best that I have come up with so far:
Then in my application I would use something like:
|
|
|
This is going to be quite manual to manage because in order to be managed by LightSpeed the two types will need to be in the same assembly so they can reference each other. Since that doesn't sound like its going to be possible you will need to manage the association more manually which is the path of thinking you have gone down. I would look at using some basic helper methods like:
where internally you should look at using the native querying API rather than worrying about using LINQ, e.g. something like:
|
|
|
Thanks for the reply Jeremy! May I ask what advantages the native querying API has over LINQ? Is there less overhead? |
|
|
Yep there is less overhead in executing the query as the LINQ provider is performing a translation between the expression tree for your query in code and the native querying API. The main advantage in this case is the queries are simpler and you avoid the overhead of running through the LINQ parser. FindById queries are also compiled so they have a performance benefit if you end up accessing this multiple times in the same UnitOfWork scope.
|
|