i think this went a bit out of scope. so just to clarify, im pretty satisfied with NH, before i've decided on using it, i've done my research, and the conclusion was use NH.
this is why i noted its a theoretical question. i wanted to know the pro/cons of letting NH map the relations, and i've displayed only the cons, because i felt i was missing the pro's because of my lack of knowledge with NH. i hoped for a discussion about letting some other facility do the relation mapping by magic, vs doing it by hand. Thanks stephan your reply is informative nevertheless. On Sun, Sep 21, 2008 at 11:03 AM, Stefan Nobis <[EMAIL PROTECTED]> wrote: > ndotan <[EMAIL PROTECTED]> writes: > > > I have a theoretical question.i fail to see how nhibernate makes > > life easy for me by mapping relations. > > I don't like the mainstream and I'm not really convinced that ORMs are > a good idea, so maybe I can add a little different perspective. > > First of all: OO is not everything. Most people here and most people > in the mainstream think, that the OO paradigm the the one and only > (or at least the very best) way to develop software. I don't think so, > but even if they are right: There is much more to OO than C# or > Java. In fact I would argue, that C# or Java are quite bad example of > OO language (if you want to see a really capable OO system, take a > look at Common Lisp and CLOS... if you only want to see, that there > is a little bit more out there to programming languages than just C#, > take at least a look at Boo -- not as rich and powerful a language as > Common Lisp, but on the other side also not such a big culture shock > for .Net developers :)). > > So, if you ask, what does make your life easier, maybe the answer is: > Don't use C# or Java. :) > > But even if you are restricted to the mainstream (and for simplicity > let's use C# and .Net as the representative of the current > mainstream), you have quite some options (some are already listed by > Fabio). > > One option, he doesn't mention is to make much more use of your > RDBMS. Put as much of you logic and code directly in your RDBMS, > discover the power of the relational model (and get a bit disappointed > how far todays products are away from the power of the full relational > model -- BTW SQL is not a real relational query language). If you are > interested in this way, take a look at books like "Database In Depth" > (C. J. Date) or "Databases, Types, and the Relational Model: The Third > Manifesto" (Date/Darwen), both more theoretical, or "SQL for Smarties" > (J. Celko; more practical), and hang around a bit e.g. in > comp.databases.theory, to see what's possible. > > To put (nearly) everything of your logic in the RDBMS has to > drawbacks: First, todays products are quite a big step away from the > relational model, so many things are not as easy to solve as they > should be. Secondly, you are drawn to a single vendor, as todays > products are nearly completly incompatible (yes, with C# and .Net it's > also not easy to port to Java or Ruby or Common Lisp or whatever, but > at least two different implementations of C# and .Net exist between > which code is (very) easy to port and it is quite a bit easier to > communicate with .Net code from other languages (e.g. a library to > communicate from Common Lisp with .Net code exists) that it is for > example to reuse old Oracle Code in a new DB2 solution). > > So, you want to use C# and you are not too thrilled to put as much > logic as possible into the RDBMS. That way you have quite some code to > write and thus to test. If you are a fan of automatic unit tests, you > have to structure your application in the right way. If your > application is a bit bigger, you have quite some logic or many GUI > masks/views, you know, there will be change in the future, then you > want even more structure in your application to avoid code > duplication. > > In this case (mainstream language, don't put too much in the RDBMS), > you end up with the usual three layers: data access, business logic, > presentation (each maybe divided further). In the business layer you > don't want to mess around with masses of SQL or other data layer > things, because you want separation of concerns, testability, > maintainability, avoidance of code duplication, etc (to collect some > buzz words). > > If you reached this point, than you don't have any other option than > to use some kind of ORM. You may write your own, but even your own > mapper needs some mappings that you have to write (they may be > shorter, because you tailord your own ORM exactly for the needs of > this single application, but then you still have to write your ORM). > > So if you are in charge of an ORM, why not just use NHibernate? It's > not the only option, but I think in many cases it's the best option > (the only alternative I know of today and that I would find > interesting to play with is iBatis). NHibernate has a sound code base > (I've seen many sources over the years, open source and closed source, > and I have to say that NHibernate has a really good and clean code > base, many snippets could be used for teaching text books -- I'm > really impressed). NHibernate has helpful und insightful > developers. > > I have to admit, if I had the freedom to choose, I probably would > prefer Java and Hibernate, but in the .Net world, NHibernate is really > good and worth the effort to learn and use. > > NHibernate don't have any kind of magic, but neither does any other > ORM. If you are willing to completly leave the mainstream, maybe you > find interesting solutions but even there don't expect any magic (not > at least not too much :)) and you may even find some drawbacks. > > Conclusion: Just use NHibernate even if there's quite some work left > to do for yourself. If you have a little spare time, try to write a > small sample application without any ORM to understand what NHibernate > achives. If you have more spare time, take some looks at > non-mainstream worlds and their solutions and get involved to develop > the one and only silver bullet to all our problems. :) > > -- > Until the next mail..., > Stefan. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
