The Artima Developer Community
Sponsored Link

News & Ideas Forum (Closed for new topic posts)
Martin Fowler on Domain Logic and SQL

4 replies on 1 page. Most recent reply: May 2, 2003 12:50 PM by Yizhong Sha

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 4 replies on 1 page
Martin Fowler

Posts: 1573
Nickname: mfowler
Registered: Nov, 2002

Martin Fowler on Domain Logic and SQL Posted: Apr 3, 2003 10:11 AM
Reply to this message Reply
Advertisement
In a new article, Martin Fowler suggests that a growing gap between database-oriented and in-memory application software developers has lead to disputes about how to use database features such as SQL and stored procedures. He discusses whether to place business logic in SQL queries or in-memory code.

Read this article on martinfowler.com:

http://www.martinfowler.com/articles/dblogic.html

Here's an excerpt:

Over the last couple of decades we've seen a growing gap between database-oriented software developers and in-memory application software developers. This leads to many disputes about how to use database features such as SQL and stored procedures. In this article I look at the question of whether to place business logic in SQL queries or in-memory code, considering primarily performance and maintainability based on an example of a simple, but rich SQL query.

Share and Enjoy - I'm looking forward to some comments.


Brian Hart

Posts: 1
Nickname: briancgin
Registered: Apr, 2003

Re: Martin Fowler on Domain Logic and SQL Posted: Apr 6, 2003 8:09 PM
Reply to this message Reply
The issue of project team comfort zones is a large one. Each team member has a 'comfort zone' as Mr. Fowler indicated that his 'comfort zone' is now OO but was once the accused 'data modeler'.

I think there is a third group that participates in the debate besides the 'data modeler' and the 'object modeler' I call them the 'transformation/document modeler'. I'm not sure if 'transformation/document modeler' is the correct phase. But on many projects there is increasing debate for business owner/decision maker mindshare on problem solving using one of the following broad categories:

1. OO techniques and EJB 'in-memory' java objects. These are theserverside.com regulars. Folks that I think Rod Johnson does a good job of arguing against 'J2EE patterns' but getting back to 'patterns'. Many J2EE patterns are not patterns but work-arounds for the specification.

2. Database vendor tools: Oracle 9i features and custom developed PL/SQL packages, constraints, views and many other DB technologies. I specifically target Oracle because they have large market share and many IT Consultants are out there pushing Oracle based 'out of the box' solution according to representatives of this approach.

3. DHTML/Schema/xml/xslt proponents.
As web based projects continue to move beyond Model View Controller with Database transactions agreeing on an technical approach can become more difficult to resolve. Sites that involve, new applications and portlets, legacy system integrations, dynamic unstructured and structured content, personalization, ADA accessibility and non-browser clients this third group is increasingly providing compelling arguments to leverage their 'comfort zones' in areas that are often viewed as the 'data modelers' territory' or the 'object modelers' territory.

I hate to come off like its a 'territorial' thing, but developers and architects can be territorial for lack of a better phrase.

Chris Rimmer

Posts: 117
Nickname: rimmer
Registered: Apr, 2003

Re: Martin Fowler on Domain Logic and SQL Posted: Apr 7, 2003 8:10 AM
Reply to this message Reply
An interesting article, which addresses some issues that I have myself wrestled with. Since I live mainly on the database side of the fence, I decided that views were a good place to encode business logic. Something that was not mentioned in the article:

If you are using an enterprise class database, then you have probably paid a heap of money for an optimizer. If you then just use it as some big black bag to hold data, you've wasted that investment. If you use views as outlined in the article, then the optimizer comes into play. Should the distribution of the data change, then the way it is accessed will also change. This all happens dynamically. If this data was being handled in-memory, then you'd have to go in and change the algorithm yourself.

Chris Rimmer

Roustem Karimov

Posts: 1
Nickname: rkarimov
Registered: Feb, 2003

Re: Martin Fowler on Domain Logic and SQL Posted: Apr 14, 2003 11:41 AM
Reply to this message Reply
The amount of the code you have can also affect the application maintainability. IMHO, in some cases a few lines of SQL are easier to maintain than hundreds of "simpler" lines of code in other programming language.

Yizhong Sha

Posts: 1
Nickname: shaliba
Registered: May, 2003

Re: Martin Fowler on Domain Logic and SQL Posted: May 2, 2003 12:50 PM
Reply to this message Reply
I think scalability is another important factor that drives the decision. The domain model may work fine when the data sets it needs to examine are small, but as enterprise data start to grow, the amount of data that need to travel between database server and application server (usually across machine boundary) can really be the bottle neck.

Another comment is that database stored procedures can also
return results sets, carefully designed database interface through database procedures and functions in addition to views can also help to promote code reuse and eliminate duplications in SQLs.

It's a great article!

Flat View: This topic has 4 replies on 1 page
Topic: Throw Away the Internet: Start All Over Previous Topic   Next Topic Topic: Final Draft 3: JavaServer Pages 2.0 Specification


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us