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-custom-dal<http://ayende.com/blog/1132/more-about-object-relational-mappers-vs-custom-dal> - *The false myth of encapsulating data access in the DAL- * http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal - 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.
