Skip to main content
Home Forums Silverlight Programming .NET RIA Services Shared entity not working
9 replies. Latest Post by theo67 on July 10, 2009.
(0)
theo67
Member
514 points
172 Posts
06-30-2009 3:57 PM |
There is now the possibility to define entities in a shared DLL. As far as I understood the client side proxy generator should be "smart enough" to detect if an entity is referenced from an external project. If so, it shouldn't generate a client side entity representation. Well I tried this:
- define a new Silverlight App in my solution and add the entity class in this project
- reference this entity in my real Silverlight client app
- define a normal .Net library project and include the entity as reference (class is not copied, but referenced)
- reference this .Net project in my web service project, which exposes the domain service
Unfortunately the silverlight client app still generates a partial class for the entity. But since all the properties are excluded, you now have an incomplete definition, so a useless client side entity.
I do see a problem with this approach, because the client side entities now no longer implement the property changed events, something I don't necessarily need in my server project. Maybe this is a dilemma as well.
What I did discover and something I experienced as a major drawback in the case of the entity generation was the fact that the meta data was copied into the client side entities. And changes in my server entities were not detected, so client and server were not always in sync. Copying the meta data felt wrong especially in the case I used XML as the external meta data provider. So I have an XML-file in my web service project describing the entity meta data, but this info is still copied into the client side entities..... Is this by design?
Theo.
kylemc
Participant
1462 points
250 Posts
07-06-2009 10:48 AM |
Which release are you working with? Shared entity codegen has been updated significantly for the upcoming release. You may find some of these issues will be resolved then.
Kyle
07-06-2009 2:05 PM |
I'm using the Sl v3.40624 bits.... a RIA refresh would be awesome but I'm a bit scared it will break other stuff..
roncain
434 points
88 Posts
07-06-2009 2:47 PM |
The next preview will be compatible with SL3 40624. One enhancement is a ".NET RIA Services class library" that allows code-gen between a SL and a .NET class library. This cleans up a lot of issues with shared entities, and I'd encourage you to give it a try.
I'm confused about the steps you described. Could you restate them a little more precisely (e.g. which project do the files live in, do you mean "link" when you say "reference", what does the raw entity look like -- that sort of thing). Maybe the coffee is too weak today, but I couldn't follow the steps.
It sounds like you defined the entity in the SL project itself, round-tripped it via the WAP, and then find it (correctly?) skips the generation of properties it finds you already defined. If you have defined entity properties in the SL project, then it is by-design that we don't generate a redundant copy.
I also don't follow the second observation. You say the metadat is copied to the client (correct) but that the server and client are not kept in sync. In what way are they not kept in sync? I see you are using the external Xml file, but even so, once you build, the client should inherit copies of the metadata from the server. And that is by design.
I'm interested in understanding this scenario better if you could clarify some of these point.
07-06-2009 3:18 PM |
roncain:The next preview will be compatible with SL3 40624. One enhancement is a ".NET RIA Services class library" that allows code-gen between a SL and a .NET class library. This cleans up a lot of issues with shared entities, and I'd encourage you to give it a try.
Wow, I'm eager to use it. Is there a seperate Connect program for this? This link http://silverlight.net/forums/t/105168.aspx describes the solution structure we have. I hope that makes clear what we're doing.
roncain:I'm confused about the steps you described. Could you restate them a little more precisely (e.g. which project do the files live in, do you mean "link" when you say "reference", what does the raw entity look like -- that sort of thing). Maybe the coffee...
He, he, blame me and not the coffee.
I have set it up like this:- created a standard Silverlight solution with a web project and the silverlight app- I manually added a RIA-project and referenced it in the web project. In this project I will create my domain service.- I manually added a silverlight project for the actual UI-content. So my original silverlight app remains small. I added this project to the web app, so the XAP-file will be included in the web project. Now the silverlight project will have access to the exposed domain services as well (*)- I manually added a Silverlight project where I define my RIA entities. These are hand coded entities (since we can't use the Entity Framework for a while). I have decorated the entities with meta data.- I manually added a standard .Net project where I link (include) the sources from the project above. I need to do this since I need a dual binary-set. So the entities are build as a Silverlight DLL as well as a normal .Net DLL (don't blame me, because the binaries are not compatible). See PRISM, since they also do things like this.- I reference the Silverlight version of the entities in the silverlight front end project and I reference the .Net version of the entities in the RIA-project.- Now the Silverlight project will get an incomplete definition of the exposed entity.
*) note that this introduces the problem that *all* of the domain services exposed in the web project via the sub RIA-projects will be codegenned into all the silverlight content projects. We wanto to have one silverlight content project per application module ("Financials", "Sales order", etc). Now all of these projects will have domain contexts for all domain services, even if they don't use them. This is not good!
roncain:I also don't follow the second observation. You say the metadat is copied to the client (correct) but that the server and client are not kept in sync. In what way are they not kept in sync?
When I change the meta data in the server, the client side proxy was not regenerated. It would only be regenerated when I explicitly delete the generated class in the silverlight project. Maybe it doesn't look at the meta data attributes when it looks for changes.
roncain: I see you are using the external Xml file, but even so, once you build, the client should inherit copies of the metadata from the server. And that is by design.
07-06-2009 3:46 PM |
I'll look over your project some more tonight after I get some preview stuff done. Sounds like a good scenario to understand.
Till then, a couple points:
You definitely want to be looking at the .NET RIA Services class library in the July Preview. It lets you pull the separate domain services and their associated business logic into a pair of class libraries, one for the server and one for the client. All apps then just take references to their respective library. Notably, the SL app takes *only the references it needs* solving your issue of getting all domain services (I agree with the "This is not good" quote, but it is now "This *was* not good" :-))
The Xml metadata sample was only a sample, and it is currently out of scope to get this into our v1. Hence, we can't really exploit it explicitly. On the other hand, the scenario you describe should work. If proxies are not being regenerated, I suspect there is a missing build dependency. Could you look at the project build order and build dependencies to verify the order looks correct to rebuild the server side stuff first and then the clients? Normally we control this build dependency by setting the "Enable .NET RIA Services" option, but we witnessed some issues when migrating existing projects forward that this dependency got lost. Does the proxy code get regenerated if you build multiple times? If so, that's a build dependency problem. If not, then there is something deeper at work. One thing I often do to debug is to open a VS CMD prompt and type "msbuild mySolution.sln /filelogger" and then peek at the generated msbuild.log. The code gen task is "CreateRiaClientFilesTask" and it logs some useful information. You can also see whether the build order looks correct. Note that the Silverlight Tool set itself had a problem with the build order when building from the command line (it didn't do dependent class libraries first) which should be resolved in any recent drops of the SL Tools -- you may already have it with 40624.
07-07-2009 3:47 AM |
roncain:You definitely want to be looking at the .NET RIA Services class library in the July Preview. It lets you pull the separate domain services and their associated business logic into a pair of class libraries, one for the server and one for the client. All apps then just take references to their respective library.
This sounds very good. Will this scenario also support lazy loading of the client side DLL's? In that case it would be impressive! This approach probably solves an issue I had: on the client you need the INotifyPropertyChanged overhead on the setters for databinding, but the server entities don't really need this overhead. I wonder how this will work with a shared concept like a "Customer". A Customer-entity will be part of the several domains, so it will appear in the Order-entity, the Invoice-entity, etc. Invoicing can be a seperate application module, so can SalesOrders be. Well I guess in that case the UI has to fetch the Customer via a CustomerDomainService when it wants to present the customer while looking at an order. Let's wait for the July preview...
roncain:The Xml metadata sample was only a sample, and it is currently out of scope to get this into our v1. Hence, we can't really exploit it explicitly. On the other hand, the scenario you describe should work.
A that's a pity. It would have been very nice to have a meta data repository on the client. We have a similar thing in our application: we build entity definition based on the meta data and at runtime we use that instead of reflection. I was hoping this XML-meta data would work in a similar fashion.
roncain:If proxies are not being regenerated, I suspect there is a missing build dependency.
This is not a big issue. I tested the problem and it happens when you edit the XML-data and press run (F5) without doing a full build. Everytime you explicitly build the solution, everything is in sync.
07-10-2009 9:30 AM |
roncain:You definitely want to be looking at the .NET RIA Services class library in the July Preview. It lets you pull the separate domain services and their associated business logic into a pair of class libraries, one for the server and one for the client. All apps then just take references to their respective library. Notably, the SL app takes *only the references it needs* solving your issue of getting all domain services (I agree with the "This is not good" quote, but it is now "This *was* not good" :-))
I have installed the latest bits and it indeed works as described, well done. So I already had the project structure in place before this, so the change was minimal. Now I see that the silverlight project only generates proxies for the referenced domain service project. Still not sure if that's sufficient for the future when you want to do cross domain project postings (CustomerDomain might be in project X and OrderDomain is in project Y. When Sivlerlight project Z wants to lazy load the customer, it will still get all the proxies from project X. You probably only want the proxies for the domain services you consume).
Next I noticed that there was no "lazy load referenced DLL's" option in the project properties, but I will post a new thread for this.
07-10-2009 10:25 AM |
That's good to here.
I'd like to understand the 'project Z' scenario above better. If you packaged X, Y as independent .NET RIA Services class libraries, then wouldn't project Z use only X? Or are you saying you want to shape the data so that there is some association between Customer and Order between those 2 different domains? As long as project Z has no actual RIA Link to the Web project and relies strictly on assembly references to library X, it shouldn't have or even see proxies for Y. The July 2009 Preview has an overview document that shows some project structures that hopefully make this clear.
I'll comment separately on the lazy load thread to keep the current one pure.
07-10-2009 11:30 AM |
We have entities that are common concepts. One of the is Customer. Now I'm not sure since I haven't modeled the domain services, but either:
- my order view in RIA client project Z has to aggregate the Customer entity coming from domain service project X- or my domain service Y has to expose this Customer entity by calling domain service X under the covers
I have a hard time envisioning the partitioning of these entities/domain services. I remember this recent restriction that only one entity type can be served by one domain service. So if I model by OrderEntryDomainService as a facade around my order, orderline and customer entities, where customer is an "imported entity", it would work I guess. So in this case my OrderEntryDomainService would have some "GetCustomer" method. But this doesn't fit with the nested domain contexts scenario. Maybe I need to experiment a bit more. Anyway I have a 3-week holiday break now, so maybe I return refreshed and inspired ;-) Thanks for the major improvements so far and the replies.
Shared entity not working