Hi,
The problem is that the generated proxies are not of the kind you'd
expect.
For example, if you have an entity like this:
public class Person
{
public virtual PersonDetails Details { get; set; }
}
And you have lazy loading enabled for property Details, the actual
property value will be of a type generated by NHibernate (actually, by
the class generator in use) at runtime which inherits from
PersonDetails. What happens is that WCF does not know this type, also
you cannot tell about it with KnownTypeAttribute, because it only
exists at runtime.
One option is to disable lazy loading and setting fetch mode to join.
I assume the actual class will be kept.
Another option is to pre-generate the proxy classes using NHContrib's
Proxy Generator project.
Let us know what follows, will you?
Regards,
RP
On Mar 18, 12:42 pm, "F.B. ten Kate" <[email protected]> wrote:
> The error i'm getting is: System.InvalidOperationException: There was
> an error generating the XML document. --->
> System.InvalidOperationException: The type SectorProxy was not
> expected. Use the XmlInclude or SoapInclude attribute to specify types
> that are not known statically.
>
> I don't want to use DTO's since i feel it's just overhead which brings
> more work when it comes to maintenance, at the moment i'm simple
> taking the filled proxy classes and use those to create new
> representations of the actual classes the serializer expects and thus
> replace the proxy.
>
> Basically the lazy load properties (which sometimes don't need to be
> fetched which is why i dont just tell em all lazy="false") get loaded
> properly, but then the serializer choaks because it's not expecting
> SectorProxy, but it's expecting an instance of Sector instead.
>
> Obivously taking the proxy's and then creating new instances is a
> valid solution to keep the lazy loading without having to use DTO's,
> but somehow it's not as "pretty" of a solution as i'd like :)
>
> On 18 mrt, 11:20, John Rayner <[email protected]> wrote:
>
>
>
> > Best approach here is probably to map your entities into DTOs for
> > serialization.
>
> > WCF (i.e. the DataContractSerializer) is able to neatly handle
> > serializing proxies ... I haven't attempted using the XmlSerializer
> > against a proxy. What error are you getting?
>
> > Cheers,
> > John
>
> > On Mar 17, 2:40 pm, "F.B. ten Kate" <[email protected]> wrote:
>
> > > Hello nhusers,
>
> > > I've been working with NHibernate a few months now and am starting to
> > > get the hang of things. Currently i'm running into a snag though. I'm
> > > returning object graphs from webservices, so far so good right?
>
> > > I've gotten around the circulair reference problem by using
> > > ShouldSerialize{FOO} patterns in different classes (not ideal but i'm
> > > not allowed to use anything above .NET 2.0 so WCF isn't allowed >.<)
>
> > > Current problem i'm attempting to tackle is Proxy Classes, since the
> > > graphs are rather large i want most of my properties to be lazy loaded
> > > (simply because users can enable/disable properties when calling the
> > > webservices). I'm not allowed to use lazy loading on properties though
> > > (i am allowed on collections) because webservices don't expect they
> > > need to serialize Proxy objects.
>
> > > Even if i Initialize the properties using
> > > NHibernate.NHibernateUtil.Initialize() they are still thought of as
> > > Proxy object.
>
> > > Is the any best practise to handle this problem?
>
> > > Greetings,
>
> > > Folkert
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
