I am in need of a data access layer that is very light weight. I have two big requirements: many different dbms systems and no third party data dlls outside of the data access layer. Basically, I need to call a method on the data layer like getWidgets() and only our widgets can be returned.

NHibernate comes really close but it keeps replacing my collections with its proxy collections. Is there a way to disable this?

I have figured out that I can set the mapping file to default-lazy="false", however that does not entirely do it. I need the collections to be my classes only no references to NHibernate or Iesi.

If I set the bag to lazy="false" then I get whole object graphs loading which is not what I want. So, is there a way to keep the objects lazy loading without using the NHibernate collections?

For example, I have a foo which has collection of bars underneath of it. If someone wants a foo I will return a foo. If someone wants a foo with all its bars then I will load the foo and add all the bars to its collection.

Basically, I will only be using NHibernate for query translation/object population. Not for object tracking or anything like that. Is there a way to do this?

If not, does anyone know of any other simple ways to do that? LinqToSQL is probably dead and SQL is not all the dbms vendors I need. EntityFramework is too invasive and too far off.

NHibernate replacing your collections with proxies is a good thing. If it did not do that you're going to end up loading the entire database into memory. However because the proxies implement the various collection interfaces there is no design time leakage and you do not need to reference NHibernate outside of your DAL.

I suppose my question for you is why you have an issue with run time proxy usage (it's not one of your two requirements)?

In the typical design usage, I would probably agree. However, in this usage I disagree. I won't end up loading any more of the database than I would have normally, we have very specific database requirements which will fill the objects (and only those objects) that I need.



Definately disagree here. If I deliver the object off my server, the NHibernate libraries must exist wherever the objects end up. Even if they are not directly referenced but used, the library must exist on the target sytem.

Off server access is definitely a different class of problem. As I indicated here http://forum.hibernate.org/viewtopic.php?t=983728#2376546 I use DTOs in this situation.

Which is at the core of my problem. If I have to hand DTOs around off system everywhere then all I really need from NHibernate is dbms access and query translation. Its a pretty small subset of NHibernate functionality.

As such, it would be nice if there were settings to swith off all the proxy classes etc. I have created some methods that strip off proxys and replace them with my classes when returning them from the data layer. It would be nice if I did not have to do that.

Is lazy="false" what you are looking for?

There are (at least) 2 levels of laziness: class and collection.
You can set lazy attribute at class mapping and collection mapping (map/bag/set/etc)

...duplicated post...

Its close, setting the lazy=false for class works. If I set lazy=false on the collections then the whole object graph will get eagerly loaded which I dont want.

What I do now is set default-lazy=false for each file, which means all classes get eagerly loaded. Then I set lazy=true explicitly on collections. In my dal I connect the session query the objects and any children. Then I close/disconnect the session and recursivley remove all the proxies.

I do all this by injecting code into NHibernate types so it runs pretty quick. However, its still a lot of overhead.

My intention is to get everything working as it is (using my hack above). Hopefully, when I get further along in the project I can get into some the NHibernate code and create a config file option that basically does all this for me.

If I dont get to this then obviously its not enough overhead to make it worth doing ;)

What about putting

in collection mappings?

It should help to minimize the overhead if you are sure a particular collection will always be needed.