A tale of two different methodologies for sure. I was disappointed that so much time was spent on the sproc debate. I feel like Ted’s points were only applicable to the edge cases which are very few when it comes to a whole application. It also seems that Ted just thinks writing SQL is less work than good old expressive OOP.

The other key point that was not mentioned during the vendor neutrality and portability section was that NHibernate IS optimized to a particular vendor’s database. Ted assumes that because NHibernate is database agnostics you loose all the powerful vendor specific features of the rdbms. Not True!! Look at how paging is handled; the SQL 2005 Dialect uses very vendor specific code that is highly optimized. Code that the average MORT DBA would probably not implement out of the box!

While it was never really discussed Ted’s arguments seemed that they were a little performance related as well. Don’t we all know that performance is the thing you tweak last? And thank god NHibernate is so flexible that you could easily write a sproc to handle a specific operation if you had to.

As for exposing a sproc as a service…. Ludacrious!! The whole point of the service is loose coupling and how can database specific sproc be considered loose coupling. But wait…. Its too much work to build a message object.

I don't see anything wrong with implementing business logic in the database as you pretty much are doing exactly that anytime your write a reporting sproc or use a trigger, etc. However, it seemed that Ted was arguing that something like UpdateAddress would be fine to implement as an spoc. I don't really see the logic in this as these kind of processes would seem to be better implemented and maintain in a OO language than in a relational language like TSQL. An old system at my company is littered with these kinds of sprocs and nearly all of them would be more readable and maintainable in an OO language. Another argument for Ayende's view is that by putting your business logic for something like UpdateAddress into a service outside of the database, you can make use of business logic already written inside the application itself by using shared libraries, etc. For example, if UpdateAddress is supposed to do any validation, if it is an sproc, this validation logic can only be used on that specific database, but if it is in a shared library, if can be used anywhere in the application (like in a web GUI where you want your controls to use it to prevent certain data entry)..

I'm also a bit confused with what Ted was calling an "extra layer" by putting an OO service on top of the database. Wouldn't this service be talking directly to the database just as an spoc would? So, in case 1 you talk to a service that talks directly to the database via ADO dynamic queries (or something like that) and in Case 2 you talk to an sproc that talks to the database directly via TSQL. How is Case 2 less layers than Case 1?

I think they should have put you and me against each other... I'm not sure what we would have talked about, but the picture of us staring each other down would be ridiculous!

Actually I'm not sure it would fit in the same picture, well, not with any detail. It would have to be zoomed out quite a bit.

Congratulations on the discussion. I've listened to it once and intend to listen again, mainly because I had trouble figuring out exactlly what Ted was arguing for or against!

Ted really lost the plot, however, when he started advocating db4o as a good solution. I've spent a good few (too many) years in the object database space and they're just a nightmare when it comes to querying and reporting on your data. Implemeinting this sort of solution just moves the dual schema problem out to your databases.

I recall being on the comp.databases.object newsgroup when db4o was first being designed. Its initial purpose was to provide something that would perform better than relational databases, and the guy developing it spent quite some time developing his benchmarks to prove his case. I'm suspicious of any solution designed primarily to improve on performance.

Congratulations on maintaining your composure in the face of "you're wrong, you're wrong, you're wrong..."

Ted used a fair few cheap debating tricks, which I would have called him up on very quickly...

Very good show ... great debate.

My view is it all boils down to a simple question:

Do you view your domain model as a representation of your database, or do you view your database as a representation of your domain model?

Java people tend to fall into the second camp, MS people tend to fall into the first. However, good for us all, we are now seeing a permeation of view between the two worlds.

However ... I have to disagree with Ted strongly on one point.

There should never be business logic within a stored procedure.

Data logic perhaps (reforming your data, concatenation of data, etc) ... but never a business rule (like calculating a sales tax total).

You were too nice to Ted, Oren :) He made a lot of bold claims but you didn't ask him to back them up one by one. Everyone can claim a lot during these kind of discussions but what the opponent should do is ask for proof/theory behind it etc. Often claims then fall flat on their face.

You did good though, hats off :)

Oren

He used a few circular arguments to try to stop you poking holes in his arguments, i.e. he railroaded you by getting you to admit you agreed with him about something that was not what you were actually trying to highlight, and hence closed off the avenue of discussion before you got to highlight your point, I got quite annoyed with him listening to it actually.

And I am sure at one point he just said something like “you’re wrong, you’re wrong, you’re wrong” i.e. like a politician talking over someone to stop them making a valid point.

Still I have to admit things got better in the second half... I wrote the comment after listening to only the first half!

I just hope you had a good drink with him afterwards!

Alex

Quoting Casey:

"Do you view your domain model as a representation of your database, or do you view your database as a representation of your domain model?"

What I took away from this is that you eventually have to do both. Start with DDD in V1 stick with DDD in V2 if you can, and accept that in some cases this may not be possible.

@Oren

You did very well, much more open minded than I expected great points!

@Ted

If I were writing a client only app and needed persistance db4o might be something I would investigate for storage, provided no reporting is involved.

Once again let me stress the need for better tools in this space. We go to great measures to shield end-users from the underlying complexities that arise from their needs. As developers we need to understand these complexities and have tools that make the management of these complexities as painless as possible. Even if you have the luxury of DDD you need tools to manage schema versioning and mapping in a manner that makes the developer more efficient.

nHibernate is a fantasic OR/M that will benifet greatly from a DSL Tool such as Activewriter, this tools deserves much more attention from the nHibernate community.

What a great debate, in the end we are stuck with the mapping complexity and we need to continue to evolve tools that ease the pain.

Uh oh, two Mikes! I'll go by Mike G

Casey,

Shouldn't it be ok to have business logic in a report? For performance reasons, a lot of reports need to stay in stored procedures, and a report could easily need to calculate something like Sales Tax...

@Mike G

And I will go by Mike D :-)

@Frans

I agree with the idea that the model should drive everything, before you even begin to think about how to store and access the data. The ER way of thinking seems to be a good way to solve business problems, but I'm not sure of the best way to use it yet. For example, with your orm tool, entity mirrors are created directly off the database schema. Is it wrong to think of these mirrors as the actual entity definitions, where custom properties can be added, behavior built in, etc...? If this is theoretically correct, then doesn't the class definition become the entity definition, and the database is just used to store necessary entity state? If this is also true, doesn't this make the class no longer a mirror, but instances of the class are now the actual entity instances?

Oh, and the reason I ask the last question is that I'm relatively new to ORM and ER theory, and am trying to see how Hibernate fits into the whole thing :)

@Mike G: LLBLGen Pro reverse engineers the relational model to an abstract entity model at the level of NIAM/ORM (http://www.orm.net). This is an abstraction level above E/R model. E/R Model is a 1:1 mirror of the tables which isn't abstract enough, for example in NIAM you can model inheritance of entities and in E/R you can't.

When I mentioned 'abstract entity model' I meant a model at the level of NIAM/ORM. :)

How entity, table and class relate to eachother is a somewhat complex subject ;). You have an abstract entity definition. This leads to a table definition (or multiple table definitions). You then define a class definition from that same entity definition. The row in the table (or rows in tables if you use entity inheritance) is the entity instance. The object created from the entity class is the an entity container. The data in the entity object is a mirror of the entity instance.

This way you can manipulate an entity via its mirror and then persist the changes you made to the REAL instance in the db.

I wrote an essay about this, it's in Jimmy Nilsson's ADDDP book and also online here:

http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx

Don't let the title fool you, I'm not promoting 'table 1:1 entity mapping'. :)

Mike G:

Shouldn't it be ok to have business logic in a report? For performance reasons, a lot of reports need to stay in stored procedures, and a report could easily need to calculate something like Sales Tax...

Personally, my view is no, it shouldn't. Here are a few of the reasons why:

• Business logic is something that should be under the control of (in order of preference) The Business Users, The Business Analysts, The Developers, and very last, the DBAs. So every attempot should be made to pass control of business logic forwards towards users, not backwards towards DBAs.

• Business logic is liable to change frequently, and as such it should be easy to change, and changes should be low impact. You could argue a SP provides that, but in reality a SP is just an API on top of a database, and as such SPs aren't a very good API - a web services layer on the database server would be better, a web services layer on an application layer is better still.

• SPs and databases are the least scalable parts of the application, and business logic typically consumes a lot of resources, you can scale applciation servers quickly and cheaply, database servers are expensive and high impact to scale.

• Reports (or other things that need to report on data directly) really shouldn't. Provide a clear abstracted layer to your database for all uses of the database by all means, but SPs aren't really a good solution for that. Better still, provide a set of services that your reporting tools can call upon to manipulate the data they get.

• TSQL is a terrible language for expressing Business logic, and also brings a host of other problems, like weak typing, poor tools, and a horribly leaky abstraction. You could use C# or similar to boost the power of your SPs ... but then you have effectively done what I suggested above, provided a set of services to wrap your business rules, so why is the SP there anyway?

• A properly designed application layer can add way more than a SP can do, for example highly specific caching and complex manipulations and filtering. Try doing that in TSQL and you are in a world of pain.

Business logic within stored procedures is just wrong. Every rule is made to be broken, but I haven't yet found a case where this one has been for a positive benefit. I have however seen dozens of systems where the whole problem with the apllciation is an attempt to use SPs to wrap business logic.