Coffeehouse Thread

40 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Where do you implement business logic?

Back to Forum: Coffeehouse
  • User profile image
    jmsma2005

    Where do you implement business logic?

    One side is architects who love and put their whole career in Middle-tier. Another side is passionate DBAs who worship data integrity so much that they insist on putting them in stored procedures.

    Seems both side have their edges and shortcomings. I have witnessed serious conflicts between the two camps.

    What’s your opinion?

  • User profile image
    phreaks

    jmsma2005 wrote:
    

    Where do you implement business logic?

    One side is architects who love and put their whole career in Middle-tier. Another side is passionate DBAs who worship data integrity so much that they insist on putting them in stored procedures.

    Seems both side have their edges and shortcomings. I have witnessed serious conflicts between the two camps.

    What’s your opinion?



    I am a fan of the middle-tier, although I can appreciatte that some things are better left in the back.

  • User profile image
    Minh

    The less data is sent onto the wire, the better your app will perform.

    I've seen that -- where performance is an issue -- putting the business logic on the Data side is the only way to go. But at the cost of maintenability ie people who know SQL well.

    But I think the performance / scalability gain far outweights the cost of sending your staff to a week of SQL training.


  • User profile image
    phreaks

    Minh wrote:
    The less data is sent onto the wire, the better your app will perform.

    I've seen that -- where performance is an issue -- putting the business logic on the Data side is the only way to go. But at the cost of maintenability ie people who know SQL well.

    But I think the performance / scalability gain far outweights the cost of sending your staff to a week of SQL training.




    Just because you implement you biz logic in the DB does not inherintly mean better performance or scalability.

  • User profile image
    Minh

    phreaks wrote:


    Just because you implement you biz logic in the DB does not inherintly mean better performance or scalability.

    Sure it does.

    Let's take a simplistic function. I want to get a list of accounts that has > $100,000.

    If you were to filter your collection in the business layer, then (naively) you'd pull back the entire table, then loop through the collection one by one.

    The data layer has much more intimate knowledge about your data & can optimize the heck out of it.

    This is obviously a trivial example, so I'll think up some more realistic ones.

  • User profile image
    blowdart

    Minh wrote:
    
    Let's take a simplistic function. I want to get a list of accounts that has > $100,000.


    Fair enough, but sometimes it's better to do things in the middle, even with data. After all SQL's string functions suck Smiley

    Also you're assuming it *can* be done at the backend. What about validation that checks against, for example, a SAP database before updating a table in SQL server number 1 and Oracle server number 2?

    Horses for courses.

  • User profile image
    Larsenal

    The answer to these general questions is most often "It depends..."

  • User profile image
    phreaks

    Minh wrote:
    
    phreaks wrote:

    Just because you implement you biz logic in the DB does not inherintly mean better performance or scalability.

    Sure it does.

    Let's take a simplistic function. I want to get a list of accounts that has > $100,000.

    If you were to filter your collection in the business layer, then (naively) you'd pull back the entire table, then loop through the collection one by one.

    The data layer has much more intimate knowledge about your data & can optimize the heck out of it.

    This is obviously a trivial example, so I'll think up some more realistic ones.


    What kind of real world example is that?

    Let's talk about a sytem that talks to 2 disparate DB's and need to use data from both as well as user input to perform it's logic.

    EDIT:

    I wouldn't consider CRUD commands to be Biz logic (although fundamentally, I guess it is), but that is just me. Of course I agree that straight selects belong in the DB.

  • User profile image
    jb43081

    We put %99.99 of out business logic in the middle tier.

    For one thing, it's more portable. We have a lot of clients who don't want to be tied to SQL Server or Oracle. With the business logic in the middle tier, they aren't.

    Secondly, because of the nature of SQL, which is more of a descriptive langage at it's core than a procedural one, there are many things that are just plain easier to code and maintain in C# or VB.

    In our area, developers outnumber dba's by about 15 to one. And I would not trust a developer with a week of SQL training to write a complex business application in SQL Server 2005.

    And finally, in situations where you need to consume a third party control or service, it's hard to find ones that are written to be deployed in SQL. Sure, 2005 has the CLR in it, but that just makes it that much less portable.

  • User profile image
    MasterPi

    Minh wrote:
    The less data is sent onto the wire, the better your app will perform.

    I've seen that -- where performance is an issue -- putting the business logic on the Data side is the only way to go. But at the cost of maintenability ie people who know SQL well.

    But I think the performance / scalability gain far outweights the cost of sending your staff to a week of SQL training.




    I was thinking about this yesterday (Apparently you can host .NET in SQL Server 2005).  I was wondering whether it made sense to have SQL Server create password hashes with System.Security.Cryptography.

  • User profile image
    blowdart

    mVPstar wrote:
    

    I was thinking about this yesterday (Apparently you can host .NET in SQL Server 2005).  I was wondering whether it made sense to have SQL Server create password hashes with System.Security.Cryptography.


    Why?

    Surely the idea behind hashes is to remove plain text as soon as possible. So, even without a "middle" tier, you really should be hashing before you hit the server.

    My thinking around the CLR is that it replaces what used to be extended stored procedures with something that finally won't bring the server down if you mess it up Big Smile

  • User profile image
    JohnAskew

    I favor a middle-tier for the vast majority of cases.

    Dependecies on Sprocs makes your code non-backend-independent, non-vendor-neutral, and not a good choice for a retail application, imho. This leaves the DAL for data I/O only, and can be swapped out with a specific provider per db engine -- as your client prefers. My .02

  • User profile image
    Minh

    phreaks wrote:


    What kind of real world example is that?


    What about a Account.Withdraw() function.

    Would you implement that on the DB, or in the middle-tier? For maintenability, probably middle-tier. But performance-wise, I'd put it in the DB.

    phreaks wrote:

    Let's talk about a sytem that talks to 2 disparate DB's and need to use data from both as well as user input to perform it's logic.

    So, your bank account info actually comes from 2 DB's. You're gonna need a transaction coordinator anyway -- and you can call that "biz logic" if you want.

  • User profile image
    Chadk

    I would, unless theres alot of calculations to be done, do it on the middle tier(A webservice, i would do in most cases, as i think they are luvely)

  • User profile image
    ktr

    Minh wrote:
    
    phreaks wrote:

    What kind of real world example is that?


    What about a Account.Withdraw() function.

    Would you implement that on the DB, or in the middle-tier? For maintenability, probably middle-tier. But performance-wise, I'd put it in the DB.


    if you are caching data for fewer server hits, or maybe your app is able to work offline, that scenario is impossible. for this reason, middle-tier is always more extendable/maintainable

  • User profile image
    mYsZa

    The database functionality shall belong to database. Everything other shall be put in the middle tier - simple Smiley
    Currently we're running a project that initially was created in a way tha all the business logic was in the database. That was OK as long as the system was being developed. Now, when new requirements are added, it is EXTREMELY difficult to change the system - there is about a thousand stored procedures and there is no person that can understand it all... We're refactoring it to be more SOA now Smiley

  • User profile image
    blowdart

    mYsZa wrote:
    We're refactoring it to be more SOA now


    But .... what if the database can publish stored procedures as SOAP services?

    Big Smile

  • User profile image
    harumscarum

    mYsZa wrote:
    The database functionality shall belong to database. Everything other shall be put in the middle tier - simple
    Currently we're running a project that initially was created in a way tha all the business logic was in the database. That was OK as long as the system was being developed. Now, when new requirements are added, it is EXTREMELY difficult to change the system - there is about a thousand stored procedures and there is no person that can understand it all... We're refactoring it to be more SOA now


    Well an argument for that is there should be adequate documentation on all of your sprocs. I do agree with you and just do not understand the 150+ sproc model. I also think it always just depends.

    I swear I do not think I will ever understand SOA. I have read what I could on MSDN and IBM but am still confused. I thought the move to SOA would be a business decision not an IT one.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.