You may want to toss your question over to the NHUsers google group, but
I'll give you my feedback for as much as It'll help ;)
is this a trade off wherein we sacrifice encapsulation for performance
This. As far as I'm able to gleen, that is the correct assumption to make.
There are ways around this.
1.) Don't access the collection unless you absolutely need it
2.) Look into doing Join Fetch's during your queries when you get the data
back if you know you're going to be using that collection as a result of the
query.
3.) Look into batch or subselect fetching, this is a good loading strategy
imo
4.) Look into lazy=extra. This allows you to do counts, contains, and a few
other common collection statements without loading the collection. You will
still have to access the backing collection, but you can write a wrapper in
your model. For example:
public virtual int FastCountOfLogins()
{
return _logins.Count();
}
That will keep your collection lazy loaded until you actually need to do
something like a for each and iterate over it.
5.) Grab nhprofiler. This is one of the single best tools for finding bottle
necks in your application.
On Fri, Jan 29, 2010 at 8:10 AM, TheNephalim <robert.eberh...@gmail.com>wrote:
> I have several issues that I'm working on, because I'm a newbie at
> this, and wanted to address the one that I "solved" first.
>
> The problem was that I was noticing that all of my collections were
> not loading lazily, no matter what I did to mark them as such. It
> then dawned on me that the problem was the way I was returning the
> collection.
>
> For example,
>
> public virtual IList<Login> Logins {
> get { return new List<Login>(_logins).AsReadOnly(); }
> protected set { _logins = value; }
> }
>
> I did it this way because if you just return _logins, you're actually
> returning a reference to the private variable which violates
> encapsulation and the whole reason for marking it private in the first
> place.
>
> The problem is that the parent object, User, is a proxy. Any time
> that that parent object was accessed, for example, to set
> User.LastName, a query for each of the collections was fired. The
> solution was to change the property to this:
>
> public virtual IList<Login> Logins {
> get { return _logins; }
> protected set { _logins = value; }
> }
>
> I have run several tests in NUnit and watched the queries coming back
> to know that this is what's happening. Additionally, I used the
> following:
>
> Assert.IsFalse(NHibernateUtil.IsInitialized(testUser.Logins));
>
> It passes for the second property implementation and not the first.
>
> The question I have is this: Is there a way to encapsulate the
> private variable but still have a proxy for lazy loading, or is this a
> trade off wherein we sacrifice encapsulation for performance?
>
> Any help you can offer is appreciated.
>
> Sincerely,
> Robert Eberhart
>
> --
> You received this message because you are subscribed to the Google Groups
> "Fluent NHibernate" group.
> To post to this group, send email to fluent-nhibern...@googlegroups.com.
> To unsubscribe from this group, send email to
> fluent-nhibernate+unsubscr...@googlegroups.com<fluent-nhibernate%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/fluent-nhibernate?hl=en.
>
>
--
- Hudson
http://www.bestguesstheory.com
http://twitter.com/HudsonAkridge
--
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibern...@googlegroups.com.
To unsubscribe from this group, send email to
fluent-nhibernate+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en.
