Those are good if I'm going to use only NHibernate in the future. What if I'm going to use EF4 (or EF5) someday, or go back to using DataSets and DataTables? With a Repository pattern at least my access to the DAL is consistent across all code and abstracted so I don't have to update it. If specific HQL or LINQ gets into the source code, then we have to update a lot of source to replace the DAL. Anyway, thanks for the articles. They are very interesting reads.
I did a quick test of the same data in EF4. Memory usage was roughly 40 MB for initialization plus querying a single customer vs. NHibernate's 150 MB for initialization plus a single customer query. It is a significant difference and likely acceptable. I'd still like to get NHibernate down lower if it is possible because I prefer its flexibility compared to EF4. Any other layers I should look at? Thanks. On May 16, 2:14 pm, Walter Poch <[email protected]> wrote: > I don't think that sharing a big fat DAL is a good approach. Look at this > posts: > > - Repository is the new Singleton - > > http://ayende.com/blog/3955/repository-is-the-new-singleton<http://ayende.com/blog/3955/repository-is-the-new-singleton> > - The DAL should go all the way to UI - > > http://ayende.com/blog/3958/the-dal-should-go-all-the-way-to-ui<http://ayende.com/blog/3958/the-dal-should-go-all-the-way-to-ui> > - More about Object Relational Mappers vs. Custom DAL - > > http://ayende.com/blog/1132/more-about-object-relational-mappers-vs-c...<http://ayende.com/blog/1132/more-about-object-relational-mappers-vs-c...> > - *The false myth of encapsulating data access in the DAL- * > http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-acce... > - Enhanced Query Object - > http://fabiomaulo.blogspot.com/2010/07/enhanced-query-object.html > > Regards, > > 2011/5/16 Kyle <[email protected]> > > > > > > > > > > > In the DAL, we create sessions and close sessions immediately when we: > > get data, insert data, update data, or delete data. We create longer > > running sessions for transactions that end with a commit or a > > rollback. Otherwise, the sessions are closed. I tried GC.Collect() > > immediately after BuildSessionFactory() and there was maybe a one meg > > change. Nothing much. As for our product, it stems from a legacy DOS > > application so most design decisions were made on that a long time > > ago, including architecture. We use a wide array of methods of > > sharing info between processes on the same machine and separate > > machines (WM_* messages, MSMQ, etc) but generally each application > > acts independently of each other. Ideally in the long term they would > > slowly merge into a common business layer, and that's what we are > > working towards, along with a new common DAL. Just the DAL is causing > > us issues right now. :) > > > Thanks again. > > > On May 16, 1:04 pm, Ramon Smits <[email protected]> wrote: > > > On Mon, May 16, 2011 at 5:44 PM, Kyle <[email protected]> wrote: > > > > Unfortunately it is a legacy application with a legacy database that > > > > we do not have the time to rework. No greenfield work here. :( I > > > > agree it is a large waste of resources, but it is what it is. I'm > > > > actually not doing any loading of data at this point. Everything is > > > > setup to be lazy from what I understand, even the domain objects. > > > > > This call is where memory goes from ~18 MB to ~165 MB: > > > > sessionFactory = configuration.BuildSessionFactory(); > > > > > I do keep the session open for an application/process right now. How > > > > can I guarantee that everything is lazy loaded? > > > > All relationship mappings in NHibernate are lazy by default but a lot of > > > beginners think lazy is slower and make them non lazy resulting in > > fetching > > > a whole aggregate or sometimes even all database data when they just > > wanted > > > to select one record. > > > > You should close the session when you can. You should have a session per > > > unit of work. Then when you want to do something again you should create > > a > > > new session. You should create a session factory once and reuse that all > > the > > > time. Creating sessions is *very* cheap. > > > > When you have created the session factory you mention that the process is > > > occupying 140mb. Is that the memory you see in the task manager? Because > > > .net is managed it will not release memory immediately. You could try to > > > create the session factory and then let the garbage collector free memory > > by > > > calling GC.Collect(). Only do this for testing purpose! Then please > > report > > > the memory is actually still using after initialization. > > > > By the way, just out of curiosity, why do you spawn all those processes? > > Do > > > all these processes run under different credentials? What is the reason > > for > > > this design. How do you communicate with all these processes? Via WCF, > > .net > > > remoting, sockets? What do you use? > > > > -- > > > Ramon > > > -- > > 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. > > -- > Saludos, > > Walter G. Poch > Sr. .Net Developer > -------------------------------------------- > Cell: +54 (9 341) 3353273 > [email protected] -- 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.
