Thanks for responding - much appreciated. I love your blog and I have to say I really admire your candor and approach to the ORM discussion that is ongoing.

Jon Galloway just told me about the ORM smackdown today and believe it or not, my post on this was really a matter of strange timing :) - I never listened to it. Anyway-

I think, in your example above, that it's only fair to also include the "under the hood" stuff you need to map these associations. In other words - I count the XML mapping as line of code too :) since this is code and it does have to be maintained.

Your code sample RE the forum bits is a great exhibition of the power of the NHibernate query tool, but at the same time it reminds me of LINQ - why not just write SQL? I understand that in many cases you'd want to abstract that stuff away in case you change DBs - so I'll give you that. But in 99% of the cases out there, the DB is pretty locked in.

In terms of perf vs maintainability - I really think this needs more consideration. To be honest, who's the app for anyway? The dev team or the client? If it's well-documented that I'm not sure that the two can't be the same. What I can tell you is that the client I cited in my post (PayPal) would have fired me if I told them that I didn't write the app for speed. I swear to you this is not an exaggeration - my PM on the job was load testing the site hourly!

Finally - the article I wrote up was mostly for the MS'ers out there. I think, looking at this from the MySQL point of view, it doesn't really apply. Views don't exist and SPs are a new construct that don't really come into play much - so the ORM model makes a lot more sense. Given the SQL Server audience, I think putting the SQL in a view is a much simpler approach than writing out code which needs to be parsed and interpreted, mapped, and then pushed through the DAL layer.

Less lines of code - more direct: (SELECT * FROM MyView).

Really finally - while I admit I am not a fan of ORM, I don't want you to see any disrespect for the work you've done. I think ORM has a great place in the development world. I just happen to think that that place is alongside the other technologies out there that work nicely :).

Thanks again,

Rob

"How do you do this with ORM? The answer: lots of code."

"Your code sample RE the forum bits is a great exhibition of the power of the NHibernate query tool, but at the same time it reminds me of LINQ - why not just write SQL?"

Surely SQL is code. And to me, it's code that's in a less sensible place than my nhibernate code.

"SELECT * FROM MyView"

And how many more lines of code to get a strongly typed collection out of that?

I'm sorry Rob but you are just shifting bits and bytes around.

Good ORM tools like NH let's you focus on the bits that are really important. If you feel that SQL is what is most important, good for you. But essentially you still need to do the same thing and without an ORM it won't even get into a nicely typed model where you need to type a lot more .net code instead.

BTW, the code Ayende showed. That is the code. NH has the capability to manage mapping based on attributes instead of config, that what the castle and active records guys focus on.

And the config to handle it is something like:

<bag inverse="true" lazy="false" name="Answers" table="Answers">

        <key column="SurveyId" />

        <one-to-many class="Answer" />

    </bag>

Not heck of a lot since I won't have to write a single join for any query I ever do for that class.

Another point:

"To be honest, who's the app for anyway? The dev team or the client?"

The client wont like it when you tell them that adding a feature will take a week in the beginning of the project and a similarly ( in the clients eyes) complex feature takes a month a year or so after deployment.

Management is not only for the developers, it's for the client. The client talks about it in the terms of "Total Cost of Ownership" TCO.

Management == Maintainability (you should have edit on your posts)

Something is always missing when people compare an ORM to data access technology X:

Saying NHibernate is a data access layer is like saying SQL Server stores data.

Both statements are true, but SQL Server does a tiny bit more than store data :) Similarly, NHibernate does a lot more than move data between your code and your datastore. I think this is often overlooked when comparing it to another technology.

It seems like I am not the only one feel 'amazed' on SubSonic way.... anyway choices is there. I have ditched Views for decades since my first ORM approach (except for certain report optimization), and I think its not related to MySQL at all. Views are not good because it creates another piece of code to maintain, like stored procedures. I can hardly understand why people love to manage 2-3 pieces of code instead of a central piece within the controller/BI layer.

A quick comment on what Rob is saying -- that MySQL doesn't support views -- then what's this?

http://dev.mysql.com/tech-resources/articles/mysql-views.html

I use MySQL for my newer projects... Or go ask Google what they use as their database! Tip: it's not MS SQL.

Other than that: I agree with Ayende and Patrik.

SubSonic allows you to just press a button and go. I'm just really lazy. I don't want to even type out things like:

[HasAndBelongsToMany(Table="UsersToRoles", ColumnKey ="User", ColumnRef = "Role")]

I just want to construct my View in my happy visual editor and then press my shiny "generate DAL" button and then go back to playing with web pages.

I understand that there's probably power behind nHib's stuff but all the configuration to get it there just seem like you're transferring from maintaining SPROCs to XML. I don't work on massive applications, and I'm not as smart as the rest of the people on this thread, but it sure feels that 99% of my data operations are simple CRUD queries. If something more complex comes my way, I'm sure I'll go with something like nHib, but for right now...