Skip to main content
Home Forums Silverlight Programming WCF RIA Services Why is the generated xxxDomainContext sealed?
4 replies. Latest Post by ericsson007 on July 3, 2009.
(0)
ericsson007
Member
43 points
36 Posts
06-19-2009 12:23 AM |
The xxxDomainContext class generated into the .Web.g.cs source file is sealed. What is the reason behind this? Can this be changed?
MarkMonster
Contributor
5220 points
1,046 Posts
06-19-2009 1:40 AM |
I don't know the reason behind the class being sealed. But what I understood: there will be code-gen-hookpoints. This might help you.
From the roadmap:
ColinBlair
6601 points
1,298 Posts
06-19-2009 10:04 AM |
I don't know the actual reason Microsoft sealed it, but generally speaking inheriting from generated code probably isn't best practice anyway. Using the codegen hooks that Mark pointed you can remove the sealed but I am not sure if it would be a good idea. Using the partial class to add methods to the DomainContext is much safer
At one point (January if I remember correctly) I was looking at the concept of inheriting the DomainContext and turning it into a ViewModel which required getting around the sealed. After Reflectoring into the plumbing of DomainContext and really getting to know how it works behind the scenes, I came to the conclusion that DomainContext is simply too complex under the covers to play around with that much, it is better to have a seperate ViewModel object which has a reference to the DomainContext instance. Generally speaking, I am looking forward to using the CodeGen hooks to do some interesting things with the entities themselves but I think that DomainContext modifications should be left to the partial class.
waldred
702 points
113 Posts
06-19-2009 2:37 PM |
ericsson007:The xxxDomainContext class generated into the .Web.g.cs source file is sealed. What is the reason behind this?
In short, the entity and context types are sealed to reduce complexity. Unsealing these types would introduce a range of additional extensibility scenarios that need to be handled and tested. (E.g., someone derives from a DomainContext and starts partying with internal state in ways we didn't anticipate or someone derives from an entity and breaks our serialization scheme.) Sealing these types now allows us to carefully consider such scenarios and leaves open the option to unseal at some point in the future without breaking existing applications.
ericsson007:Can this be changed?
If you absolutely must, you can use a CodeProcessor to unseal the DomainContext type. CodeProcessors are an advanced topic but you get complete control over the generated code output. I would recommend looking into this option if you don't mind the wilderness.
07-03-2009 2:23 AM |
Thanks for all the feedback! The main reason for this question was that I was working on subclassing the DomainDataSource to for example implement generic error handling, and still be able to easily use it in the XAML. That worked out to be no problem, and I have the same need for the xxxDomainContext. The CodeProcessor seems to some work, which I don't have time for right now, but soon :) Thanks again for all the comments!
Why is the generated xxxDomainContext sealed?