One possible thing to consider. Many of our NH and FNH mappings hit tables that are backing a vendor's application. Those tables are HUGE, complex, and follow probably every antipattern possible. For example (we're a K-12 education institution), to lookup a "student" requires hitting about 17 tables, all with different key names, data types, etc. It's a nightmare. On top of that, it's mixed Oracle 9 and 10g, which adds a layer of joy
To get around that, we have either created views/materialized views that better match the domain model (and handle the extremely complex joins at the database level). With those, we can read in our data. To push the data back down, we use functions (called by NH/FNH) rather than writing back down directly to the table. It's not the best situation and doesn't allow us to leverage the "create your objects, compile, and update your RDBMS", but it beats the heck out of having plSQL scattered throughout our applications--especially when the vendor changes a table without telling anyone. ;) For books, NHibernate in Action is good, but won't dive into FNH. It did help me when I first started with NH to figure out which mapping fit which situation. http://www.manning.com/kuate/ Also, @ayende's NHibernate Profiler is a dream come true for both using NH/FNH and LEARNING. Create a mapping, run your test, and see the SQL it generates. http://nhprof.com/ Finally, the new wikis are pretty nice--lots of coverage regarding mapping, automapping, etc. -dl --- David R. Longnecker blog: http://blog.drlongnecker.com twitter: dlongnecker On Fri, Feb 26, 2010 at 2:33 AM, diwoma <fo...@softconsult.at> wrote: > Hi Tom and Keith, > > > An introduction to nhibernate is here : (just hit google) > > google gives 'tons oh hits' with special parts how you can do smart > things with nhibernate. > In my work, I don't only read from simple tables in sql-server. > I have joins, unions, calculations over subqueries and dynamic where- > clauses over tables an join-tables. > > That was my reason to not use nhibernate, MS MEF or Linq, because it > was easier to manage the work directly in T-SQL. > But using classes is more save by programming and now I have a look to > these tools. > > maybe I should by a book for nhibernate to understand the whole tool. > > thank you for your links. > diwoma > > -- > You received this message because you are subscribed to the Google Groups > "Fluent NHibernate" group. > To post to this group, send email to fluent-nhibern...@googlegroups.com. > To unsubscribe from this group, send email to > fluent-nhibernate+unsubscr...@googlegroups.com<fluent-nhibernate%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/fluent-nhibernate?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to fluent-nhibern...@googlegroups.com. To unsubscribe from this group, send email to fluent-nhibernate+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en.
