Consolidating models?
Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2546
Printed Date: 29-Jul-2026 at 5:54pm
Topic: Consolidating models?
Posted By: midnit
Subject: Consolidating models?
Date Posted: 08-Mar-2011 at 6:39am
|
We have several models, each with its own assembly. One of these is a Common model which includes stuff each silverlight Module needs.
I think I would like to be able to include this "Common" model either in the other models, or perhaps there is a better way. I tried moving the common.edmx into one of the other assemblies and I set up the namespace, entitymanagername, datasourcekey, and container to all be the same and generated the files This does compile..but my partials in the server assembly know nothing of some of the entities that came from Common. The silverlight partials see everything.
Also, when I query on any of the entities from the "Common" edmx I get an error:
This is using 6.0.7.
Can you give me some ideas both on this problem and other potential solutions. I want to make it simple for my team and it seemed having it in one EntityManager would be a step in that direction. On the other hand it seems that they will all be under the same namespace this way? I can work with that I guess. I do want the "Common" to be the same across all models/domains. Should I stick with multiple EM's? The items in "Common" are related to security and business rules that pertain to every silverlight module and are never editable at this point (through silverlight).
Thank you,
|
Replies:
Posted By: midnit
Date Posted: 08-Mar-2011 at 8:27am
I got to a different error now
Which seems to further suggest that my partials aren't matching up. This happens on both of the entities that are defined in the common.edmx. They have the same injected class as the other model in the project.
|
Posted By: DenisK
Date Posted: 08-Mar-2011 at 7:22pm
|
Hi midnit; Could you post a screenshot or something like the following so I can visualize your current solution's structure better and the structure you're trying to accomplish ? Solution CommonModel (Windows Class Library) CustomerModel (Windows Class Library) EmployeeModel (Windows Class Library) OrderModel (Windows Class Library) SampleMultipleModels (SL Client Project) SampleMultipleModelsWeb (SL Web Project) Reference to CommonModel, CustomerModel, EmployeeModel, OrderModel LoginManager.cs Employee.cs ....etc
|
Posted By: midnit
Date Posted: 08-Mar-2011 at 11:17pm
Sure thing
 The UI are the SL host, the *Management are the actual modules. The Models pretty much match up to the modules as the names suggest. SnapShots are old and will be removed. So every module (*Management) references the Common model (highlighted) as well as its specific model. There is a little overlap in some of the models. We are considering moving everything into one model but performance is very high priority so that has to be tested.
Does that give you the picture?
|
Posted By: DenisK
Date Posted: 09-Mar-2011 at 2:37pm
|
Hi midnit; Thanks for the screenshot. 1. Your very first post seems to indicate that you're assuming each model needs its own sub-typed EM. That is actually not true. Any EM, sub-typed or not, can access any model within the same assembly. We generate the sub-typed EM to make it easy to use in terms of queries. Using your DomainModel as an example, you can easily access your Common model from Confirmation EM by using: var mgr = new ConfirmationEntities(); mgr.GetQuery<CommonEntity>().ExecuteAsync(); whereas using the Common EM, you would probably query as follows: var mgr = new CommonEntities(); mgr.CommonEntities.ExecuteAsync(); Even using a generic EM would work: var mgr = new EntityManager(); mgr.GetQuery<CommonEntity>().ExecuteAsync(); mgr.GetQuery<ConfirmationEntity>().ExecuteAsync(); As you can see, the only difference is cleaner syntax. Having multiple EMs or just 1 EMs would not make any difference in this regard. 2. Your second post about the SecAppUser error seems to indicate that the type is defined under 2 different namespaces within the same assembly. This issue has been fixed in 6.0.8. I hope I've understood and answered your questions and assumptions correctly. But if not, please feel free to clarify further.
|
Posted By: midnit
Date Posted: 10-Mar-2011 at 4:15am
|
Well that changes the light I am looking under.
So in my Domain example, Deal and Common are in seperate assemblies and namespaces. Would Deal need a reference to Common to be able to query "Common" related entities using the DealEntityManager? Or is that simply up to the hosting application to have both references or do they have to be in same namespace or assembly?
-Can multiple models in the same assembly have different namespaces or do I need to keep them in seperate assemblies for that? I am asking because as I said there is overlap in the models and that is to keep entities as slim as possible for each module - if we only need 2 fields on an entity in one module vs needing all the fields in another module. Every second counts and this stuff (Silverlight + EF + IB) leaves a lot to be desired in that department.
Another reason we have seperate assemblies is to keep testing to a minimum for deployments, if its all in one and anyone touches that one...we have to test the whole system and not just unit test.
Thoughts?
|
Posted By: DenisK
Date Posted: 10-Mar-2011 at 4:23pm
|
"Would Deal need a reference to Common to be able to query "Common" related entities using the DealEntityManager? Or is that simply up to the hosting application to have both references or do they have to be in same namespace or assembly?" Yes, you still need the reference but they don't have to be in the same namespace or assembly. "Can multiple models in the same assembly have different namespaces or do I need to keep them in seperate assemblies for that?" Yes, multiple models in the same assembly can have different namespaces.
|
Posted By: midnit
Date Posted: 21-Mar-2011 at 10:58am
| Btw, thank you for the eye opening! I have now been able to change things greatly for the better. |