"Common Lisp is a multiparadigm, general-purpose programming language that: Supports a combination of procedural, functional and object-oriented programming paradigms."
The question is not about the best paradigm to develop a solution. The idea for ORM is: if you choosen a OO language ( Java, C#, ...) is better design the project in OO world (UML) and coding OO (ORM) for a relational database. We doeas not have a OO database with the power of oracle, postgresql, etc... []'s Ricardo Borges 2008/9/21 N. D. <[EMAIL PROTECTED]>: > 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 -~----------~----~----~----~------~----~------~--~---
