These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Encapsulating data access
PostPosted: Mon Feb 09, 2009 5:42 pm 
Beginner
Beginner

Joined: Fri Jul 06, 2007 9:27 pm
Posts: 22
Can I encapsulate NHibernate in a data-access project, and keep the rest of my solution ignorant of it?

Here is my scenario: I have a solution with three projects--each one corresponds to an application layer:

-- Core (domain model and mapping files);

-- Data (database manager, which holds an NHibernate SessionFactory, and repositories, which perform CRUD operations and return objects and collections); and

-- Test (which I am using to unit-test the setup).

I am using SQL CE as my data store.

I have read in a couple of places that NHibernate must be located in the project that contains my 'driver' code--in this case, my test project. But that makes no sense to me, since one of the primary purposes of using an ORM like NHibernate would be to encapsulate data access in its own layer (project) to separate those concerns from business and UI concerns.

Am I reading NHibernate's requirements incorrectly? Can I isolate it in a data access project, or do other parts of my solution need to be aware of it? Is there anything good written on this subject from a desktop app perspective?

Thanks for your help!

David Veeneman
Foresight Systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 11, 2009 2:36 pm 
Beginner
Beginner

Joined: Fri Jul 06, 2007 9:27 pm
Posts: 22
Got the answer--it turns out that my problem wasn't an NHibernate problem at all, but a SQL CE problem. But, since it affects NHibernate apps that use SQL CE, let me explain what I found. Hopefully, it will help folks with similar questions down the road.

SQL CE is made up of the main System.Data.SqlServerCe.dll and seven helper DLLs--sort of like Snow White and the Seven Dwarves. The odd thing about the seven dwarves is that they never get copied to the application output directory, even if you specify that they should, and they never get removed when you clean a solution. Plus, when you add a reference to System.Data.SqlServerCe.dll to a project, its CopyLocal property defaults to False.

When we compile a .NET application, the compiler copies dependencies from project folders to the application output folder--the output folder of the executable that runs the app. Or, in the case of a unit-test setup, the output folder of the unit test project. Snow White gets copied (if CopyLocal is changed to True), but the seven dwarves don't.

To get the seven dwarves copied to the application output directory, you have to use a post-build event in the executable project. The post-build event triggers a copy command to force the copying. I find it easiest to put all eight files in a separate subfolder and copy everything from there, including Snow White (I leave CopyLocal set to False on the reference).

Here is what my copy command in the post-build event looks like:

copy "$(SolutionDir)SharedLibs\SqlServerCe\*.*" "$(ProjectDir)$(OutDir)"

That gets all of the SQL CE files copied to the application output directory, with the result that NHibernate is able to properly configure itself and create a session factory.

David Veeneman
Foresight Systems


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.