Separate out InvalidStateException to prevent NH and NH.Validator dependencies
Description
Environment
Activity
Fabio Maulo February 10, 2009 at 8:59 AM
I have a intermediate Interface with an injected implementation for NHV.
Probably we should work in a CommonValidation prj.
http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=46746
Gustavo Ringel August 25, 2008 at 2:04 PM
I don't see the problem referencing NHibernate and using only the exceptions. Aren't you using System.Xml, System.Data as part of the default references? Do you think that System.Data and System.Xml are part of the presentation layer? If not, why don't you try to take them out from there? You can connect to a Database also with System.Data...
You can wrap everything in your own dll and reference this dll anyway if you don't want to see the word NHibernate...but as Dario said is a matter of taste...I'm fine using a few options of System.Data and System.Xml and having the references, i'm also fine in general to have NHibernate reference in my presentation layer (not in the GUI obviously)
Gustavo.
Dario Quintana August 25, 2008 at 1:09 PM
This issue is about taste and we can get differents approach in our applications.
I know, the NHibernate dependency is evil, becuase we have to carry with every depency of NHibernate itself.
If we opt for your solution, your application is going to look nicer, but not NHV: is going to have 1 more assembly. I think the solution is not remove InvalidValues and the Exceptions (part of the core) outside, the solution is decouple the dependency on NHibernate, as much as possible.
Sukh August 22, 2008 at 5:33 AM
Referencing NHibernate directly in my ASP .NET is bad practice because it creates a dependency on an assembly that should only be used by my data layer. My ASP .NET application currently has no idea that it is communicating with an NHibernate-backed data layer.
Having a quick look at the code, I don't see why it can't be done?
Move out the exceptions from NHibernate.Validator.Exceptions to a separate assembly. Move InvalidValues too. Reference this new assembly in NH.Validator and it should all work? That way, I can catch and manage the exceptions generated on Session.Save() without adding the dependencies to NHibernate and NH Validator.
I can try submitting a patch if you like?
Dario Quintana August 20, 2008 at 11:04 AM
Separate the Exception+InvalidValue into another assembly is not a suitable option.
What is the problem with reference NH into an Asp.Net layer? Reference NHibernate, and just do not use it.
A solution could be let the user set the Exception type to work with, but here we lost the InvalidValues capability.
I'm following a n-tier structure and therefore only have NH + NH.Validator references in my business layer. However, I need to catch InvalidStateExceptions in my ASP .NET front-end, and therefore currently have to reference both NH.Validator and NH in my ASP .NET application.
The Exception + exception details (Invalid Values) should be separated out into another assembly so that I don't need to reference NHIbernate in my presentation layer.