I am looking for validation framework and while I am already using NHibernate I am thinking of using NHibernate.validator from contrib project however I also look at MS Validation Block which seem to be robust but i am not yet get into detail of each one yet so I wonder has anyone had step into these two frameworks and how is the experience like?
NHibernate Validator does not require you to use NHibernate for persistence. Usage can be as simple as:
var engine = new ValidatorEngine();
InvalidValue[] errors = engine.Validate(someModelObjectWithAttributes);
foreach(var error in errors)
{
Console.WriteLine(error.Message);
}
Of course it can hook into NHibernate and prevent persistence of invalid objects, but you may use it to validate non-persistent objects as well.
For the most part I would say that Spring.NET is pretty independent. Meaning it should not force you to re-architect. You can use as much or as little as you want. It should be pretty easy to write an object that you can inject into classes needing validation using spring. You would then wire this object up in castle to take the name of the "Validation Group" or "Validators" you needed and then have spring inject the validators into that object where your form/business object/service would then use the validators.
Here is a link to the doc,Validation is section 12:
http://www.springframework.net/docs/1.2.0-M1/reference/html/index.html
Are you just using Castle or are you using Monorail?
Of course you can try to write your own validation framework. For eg. Karl Seguin will help you:
http://codebetter.com/blogs/karlseguin/archive/2009/04/26/validation-part-1-getting-started.aspx
http://codebetter.com/blogs/karlseguin/archive/2009/04/27/validation-part-2-client-side.aspx
http://codebetter.com/blogs/karlseguin/archive/2009/04/28/validation-part-3-server-side.aspx
It's really nice solution :)
How about D) None of the above.
I remember evaluating this last year and decided on going with Spring.NET's validation framework.
If your using NHibernate your probably want to use Spring.NET's facilities for using NHibernate as well.
Related
I use NHibernate. I need to decide how validate domain entities. What do you recommend? Are there any troubles if use NHibernate with Fluent Validation?
Of the O/RM tools I know, NHibernate has the smallest footprint in the C# code of domain classes. It almost allows working with POCO's while being totally oblivious of dependencies. That is exactly what FluentValidation allows too. So it seems like a happy marriage to me.
But I wouldn't dare recommend or advise against any validation tool or framework without knowing more of your context. There are many candidates and they would work with NHibernate as well. Data access and validation are two different concerns that should (and can) be separated from one another.
Fluent validation is really good for user input validation, and can be used for simple business rules. But it has no integration with NHibernate. That means that nothing would prevent NHibernate from saving not valid entity except your custom code.
On other hand there is a NHibernate validator project. It has an integration with nhibernate, and it won't let you to save not valid entity.
Generally your domain shouldn't know about your ORM. It should be kept in isolation. So my answer is:
I Can not see any issue with NH and FNH Validation, but keep domain in isolation as much as possible.
Do mapping attributes offer the same versatility as nhib hbm's do? Can you use them together with FNH to handle things FNH doesn't yet do as well as hbm's can?
Cheers,
Berryl
By mapping attributes, I don't mean hbm files; there are apparently attributes that come with NHib (or maybe NHib contrib these days) that you use to decorate your class & class properties. I'm guessing these pre-date FNH, but not sure.
I personally prefer to create the hbm.xml files myself. I've used Fluent, but I just like managing the nitty gritty myself for things like this. However I've not run into any mappings that I haven't been able to get working with Fluent though...
It is my understanding that Fluent nHibernate actually creates an hbm.xml file in the background based on your settings that is in turn used by nHibernate... so being that Fluent is itself creating the mappings, I would argue that just creating the hbm.xml manually would technically give you more flexibility and access to the nuance of the mapping file...
I think that there is a similar learning curve for both, so if you are going to bother learning Fluent that itself creates hbm.xml files, why not just learn how to create the damn hbm.xml files yourself in the first place and skip the middle man!
Unless you are doing MANY MANY projects in rapid succession, the act of actually mapping your database is only a fragment of the actual work you are doing on a particular project.
Max Schilling
The NHibernate attributes do pre-date FNH. Apart from a relatively small group of die-hard holdouts, I don't really know anyone that uses them. They're supported, but not exactly friendly. If you like attributes, the Castle ActiveRecord attributes are a much better implementation than the NHibernate core ones.
Fluent NHibernate can work with everything else. All it does is inject mappings into the NHibernate Configuration instance, so you can put whatever else in there you like. ActiveRecord is a bit more of a wide-reaching solution, so that may be an exception to this rule, it's been a while since I've used it.
I've never run into a situation that couldn't be handled by Fluent NHibernate, but maybe you're using an obscure attribute. Anything in particular you need to know is available?
We are using them in my business and I kinda like them.
I think it is really neat writing the mapping directly in the class definition (I know - to each one his own).
I agree with most the comments here, Hibernate gives you the freedom of choice on how to implement the maps for the objects.
I prefer not to use attributes on my classes for NHibernate, as now my classes now have another dependancy which they should not know of.
What happens if you want to change your datasouce to a OODB or just a file. The classes will have redundant mapping code(the attributes). in this case it could be said, its cleaner to store the mapping in the data/infrastructure layer with the repository implementation (assumed useage of the repository pattern)
I also agree, each to they own :)
I'm trying to understand where NHibernate 3 stands in relation to Hibernate 3 with respect to attributes vs annotation. I've been on several Java projects where we used Hibernate 3 annotations for mapping. It is quite elegant as
the entitites are clearly documented where the code lives
easier to debug when stepping through the debugger...
you don't have to go open a separate file out of context
less artifacts to manage
compile time checking
intellisense = fewer typos
no need to install/learn a separate 3rd party component (e.g. FNH)
the Hibernate team invested in making annotations easy to use and integral
Not sure I buy the "what if you have to change datasources" or the "separation of concerns" arguments. In practice, those arguments are looking at the "20%" (or less) that either won't occur, or have marginal impact if they do - the benefits are far greater IMHO.
With that said, what is not clear to me is whether the NHibernate team has invested enough in making the attributes robust enough to warrant use, or would I be better off moving to EF4.x to get the same benefits... those are the answers I was hoping for from this post.
What is NHibernate Interceptor, and what purpose does it serve in an application?
Also, in this article, I learned that using NHibernate makes a desktop application slower at startup, so to avoid this, I need to save the configuration in a file, and later load it from the saved file. How can I do that? I didn't find any examples in that tutorial.
An interceptor allows you to execute additional functionality when an entity is retrieved / deleted / updated / inserted in the DB ...
Interceptors article
Hibernate doc
other useful info
About making your app slower:
I'd suggest that you only have a look at optimizing start-up time, when it really becomes a problem.
When you build a session-factory, NHibernate will parse all the mappings, and that is an operation that is a bit expensive. But, as long as you have a limited number of entities, the performance hit isn't that big.
I have never ever had to optimize the initialization of NHibernate, because of slow startup times.
I'd suggest that you first concentrate on the core of your application -the problem you're trying to solve- and afterwards have a look on how you could improve startup performance.
(If you'll ever have to do it).
Interceptors, like the name itself says, allows you to intercept NHibernate operations (save/update/delete/load/flush/etc).
A newer, more flexible API to achieve this is the event system.
About serializing the configuration, the code is there, it's the class Effectus.Infrastructure.BootStrapper which is called at application startup.
An interceptor's dissection series written by me can be found in here
http://blog.scooletz.com/2011/02/03/nhibernate-interceptor-magic-tricks-pt-1/
hope it helps
Can anyone throw some light on tools that can be used with NHibernate and which perform the below mentioned tasks:
Generates the Mapping File
Generates the Entity Class
Generates the Configuration file
And also provide information whether these tools are open source or licensed.
Thanks
One tool I've used that did a decent job was CodeSmith. It looked at the existing database and created the entities, mappings and configuration file. However, this is only to be used as a starting point as there are many tweaks you'll likely want to do to make it more usable and better performing. Things such as when to lazy load vs. eager load, creating subclasses or components. This tool really just mimics the database structure in your entities which is not always the best way to represent in code.
This is a licensed solution but it includes a fully functional demo you can use to gen your files initially. After that, you'll most likely just enhance just as you would your database.
Another is MyGeneration. Same thing, it'll get you 75% of the way there in most cases.
Just be cautious as to which version of NHibernate these tools are producing. They may be using an older version which may have some obsolete code.
I really like Visual NHibernate (http://www.slyce.com/VisualNHibernate/).
Not free, but has a nice set of features, including the definition of templates for the entities, and generating both HBM.XML as well as Fluent NHibernate mappings.
A similar question with some answers you might find useful is already on SO.
NHibernate Generators
As mentioned in that question's answers, fluent NHibernate is a good option. It just went RTM. You can find more info at http://fluentnhibernate.org/
Check out LLBLGen Pro. It's got a competing ORM but can also act as a code generator for nhibernate. Very good for DB first work.
I just want to do a quick poll to see if Fluent Nhibernate is well received or if it is having lot of issues. I like Nhibernate but I definitely see the problem with xml to do mapping.
So, I am looking forward to community members for some insight and help me pick one over the other.
I am not considering either linq2sql or entity framework at this time.
I like Fluent NHibernate and I think it's mature enough if you are going to start a new project. Using it on a new project should allow the Fluent NHibernate project to continue to mature as yours progresses. There is a possibility for breaking changes (as happened recently with the convention mappings) but you should be able to deal with those. I've had a few issues with the mappings but the project is pretty responsive to bug reports and has mostly worked as expected.
The mapping options are:
Xml mappings - Standard of NHibernate. The maintenance headaches are well known but the advantage is that you have access to all of the configuration options provided by NHibernate. There are a few less-used configuration options are still being added to Fluent (at least last time I paid attention). So, if you are anticipating some crazy mappings, you may want to consider this option.
Standard Mapping - Provided by Fluent. You can create the mappings through code and is much better for refactoring and authoring. Not much to say about it, in my experience, other then that it works well and is a big improvement on the xml option.
Auto Mapping - Provided by Fluent. Allows you to map object properties by convention and it attempts to create the mappings automatically. It's a good idea but I think it still has some maturing to do. I'm currently using this mapping method and it works fine but I have ended up writing a large number of conventions and specifying the object relationships that it doesn't feel like it's saved much effort from the standard mappings.
Fluent NHibernate also provides nice test helpers for testing your mappings and some configuration APIs that can make it easier to configure NHibernate. Overall, it's a good project and it provides some nice additional functionality to NHibernate.
edit:
One additional thing to note: If you start off with Fluent NHibernate and decide it isn't going to work for your scenario, you can easily migrate back to the xml mappings. Fluent NHibernate allows you to export the mappings it creates and you can use those exports to not lose whatever mapping work you've already done.
One of the best advantages of using Fluent Nhibernate over vanilla NH is nice integration testing with PersistenceSpecification<T>:
[Test]
public void TestProductSave()
{
new PersistenceSpecification<Product>()
.CheckProperty(x => x.ProductName, "Wax")
.CheckProperty(x => x.Price, 20)
.VerifyTheMappings();
}
I've been using fluent on a new project of mine. The only minor bump I've hit so far is that it doesn't play so well with Castle Windsor out of the box, but it was quite easy to extend Windsor to do the job. Other than that I've been loving it. It's much more concise than the XML mappings.
The nice thing about fluent is that it isn't an all or nothing investment. You can write most of your mappings in fluent and if you find any issues you can map those classes in the standard XML mapping until the fluent issues are resolved.
Like any good answer, it depends.
I didn't get as much mileage out of the automapping features as I would have wanted to. I often have to work with preexisting databases.
I already had several projects using NHibernate under my belt, so using the hbm mapping wasn't difficult. After I figured out how to include in the hbm schema, it was much easier.
The one real advantage I gained from having fluent-nhibernate is being able to refactor my domain classes and have my mappings automatically change. I didn't really notice that much of a speed increase in writing the mappings.
Like anything, YMMV.
I am using FNH for a new project. What I like the best is the ability to generate and build the database directly from the entity classes.
I have had to write a few conventions for the properties but I'd rather that then maintain more than one list for each class.