Where do you keep your business logic?

[abhijit]

I have been maintaining legacy apps for as long as I can remember. Most of these apps are two tiered apps.

There is no standardization and some developers have prefered to put the business logic in the database, while others prefered to put that in the front-end code. My personal preference has been putting the business logic in the database. This is mostly because our database is used by more than one system, so this helps me avoid duplication of effort.

In the multi-tiered world, I realize there are several places where your business logic could reside. Most people prefer to have it in the "Middleware", which is essentially a series of assemblies or java classes that act as an intermediary between the database and the client app. Several front-end clients connect to the middle tier which acts like a traffic cop deciding, which requests will reach the database and which have to be rejected. I suppose, this reduces the load on the amount of traffic hitting the database.

If you had to move your client app to a new technology, but keep the same database, would you choose to

a) create a middleware component?
b) keep the logic in the database and build your client.


What is your preference for a two tiered application and a three tiered application? Why? Does your preference depend on the application? If so, why?

[techgnome]

First, let's clear up a myth.... Multi-Tiered (n-Tiered) apps and Multi-layers apps are not the same thing... they have some cross over but TRUE multi-tiered apps will reside in PHYSICALLY separated locations...

For example, the app I worked on had a Database, with sprocs, data access layers, business components and the UI. 4 layers, but only 3-tier architecture, as only the Data access was separated from the rest. They reside on an Application server physically different from the Database and the Client. People often think that simply moving their logic or data access to other components makes it an n-tier application, even though everything is on the client. In fact, at that point, it's still client/server (2-tier) architecture.

So in anything more than a 2-tier application, the BL can only exist in one location: anywhere other than the client or database.

Unfortunately it's never quite that simple in real life. Personally, I cringe when I see BL in sprocs... sprocs should be stupidly simple. They select data. They update it. They insert new records, and delete existing ones. The DA should request the data via the stupid sprocs and fill object(s) with the data (and I don't mean a datatable or dataset - after getting the data, the words "DataTable" & "DataSet" should never appear again in code). That object should be then passed back to the requesting BL component. The BL then does any logic processing on the data that's necessary (formating, conversions, lookups, calculations, what ever) and passes it to the presentation layer. At this point, we've bubbled up to the top and the data is stupidly displayed to the user. I say stupidly displayed because the UI should be almost as stupid as your data access was... just display the data as it is, nothing more, nothing less.

-tg

[Tom Sawyer]

I always like creating a middle layer to hold business logic. Backends are for basic data retrieval, etc and front ends are for display and user interaction.

I once had to update an application that was windows based and give it online functionality that did mainly the same thing. That necessitated an almost complete rewrite of the system because all the logic was inside of the various forms. If it had been broken out properly, the project would have meant building some webforms and calling the preexisting dlls. The same would be true if you want to change databases or something.

[abhijit]

I always like creating a middle layer to hold business logic. Backends are for basic data retrieval, etc and front ends are for display and user interaction.

I once had to update an application that was windows based and give it online functionality that did mainly the same thing. That necessitated an almost complete rewrite of the system because all the logic was inside of the various forms. If it had been broken out properly, the project would have meant building some webforms and calling the preexisting dlls. The same would be true if you want to change databases or something.

How many times do you actually change databases? If you happen to be building a product, I understand the necessity of doing this. One of your customers might want the product to work with a different database.

In case of a business developing its custom in-house application, the choice of the database is made just once during the lifetime of the business.

[techgnome]

"the choice of the database is made just once during the lifetime of the business." -- I can tell you that isn't true... It can actually be made 2 or three times ... consider an app that starts off with a few users, and an Access Database... which eventually grows into a SQL Server... which grows some more into SAP... That's something we're actually getting geared up for at the moment (not the Access part). Right now everything is in a number of SQL Server databases. Eventually things are going to be in SAP. Knowing this, we're trying to gear our development so that as pieces are moved from SQL Server into SAP, we just have to replace a backend data service (we're abstracting it so it's not even data access, but a data service) with a new one that talks to SAP.... no changed to the BL or the UI... The user won't even need to install anything new... in theory, they should never even notice that there was a change.

-tg

[abhijit]

"the choice of the database is made just once during the lifetime of the business." -- I can tell you that isn't true... It can actually be made 2 or three times ... consider an app that starts off with a few users, and an Access Database... which eventually grows into a SQL Server... which grows some more into SAP... That's something we're actually getting geared up for at the moment (not the Access part). Right now everything is in a number of SQL Server databases. Eventually things are going to be in SAP. Knowing this, we're trying to gear our development so that as pieces are moved from SQL Server into SAP, we just have to replace a backend data service (we're abstracting it so it's not even data access, but a data service) with a new one that talks to SAP.... no changed to the BL or the UI... The user won't even need to install anything new... in theory, they should never even notice that there was a change.

-tg

Touché!

I should have put in "In almost all I cases I worked with".
I agree there are situations, as the one you described where the database changes.

However if a business starts off with Oracle, it is very unlikely that it will change to mySQL or SQL Server overnight.

[techgnome]

No, but they could change to SAP ... And I have seen organizations change from SQL Server to Oracle, as well as the other way around (usually a licensing/financial decision).

-tg

[leinad31]

It would still depend on the nature and granularity of the business logic... you also wouldn't want to clutter the oracle instance with too many seldom used procedures, nor bloat the database dictionary... the memory could have been used elsewhere.

[FunkyDexter]

Personally, I cringe when I see BL in sprocs... sprocs should be stupidly simple.HEAR, HEAR! To be honest, I'd argue that they shouldn't exist at all, stupid or otherwise. Even simple selects become a nightmare when porting between platforms and I remain utterly unconvinced of the benefits that are quoted for them. Unfortunatley, the last two systems I've worked on have been BL in Sproc systems and they've both been a maintenance nightmare.

How many times do you actually change databases?As you've said, it's rare but, as TG has said, it can and does happen on occasion. I've also worked on in house system that ended up getting sold extrenally. While the possibility might be rare, why would you preclude it from happening for little or no benefit? The question's not so much, "why wouldn't you use sprocs" as "why would you".

[abhijit]

HEAR, HEAR! To be honest, I'd argue that they shouldn't exist at all, stupid or otherwise. Even simple selects become a nightmare when porting between platforms and I remain utterly unconvinced of the benefits that are quoted for them. Unfortunatley, the last two systems I've worked on have been BL in Sproc systems and they've both been a maintenance nightmare.

As you've said, it's rare but, as TG has said, it can and does happen on occasion. I've also worked on in house system that ended up getting sold extrenally. While the possibility might be rare, why would you preclude it from happening for little or no benefit? The question's not so much, "why wouldn't you use sprocs" as "why would you".

Business rules revolve around data.
So keep your business rules close to data.
That's one school of thought and we have been following that school rather religiously in our shop.

[techgnome]

Agree with the first line, mostly.
Disagree with second line absolutely.

Yes, generally BL revolves around the data... but the BL should not care if the data was SQL Server, Oracle, XML, flat file or user input. You should be able to separate the two layers enough so that if one changes, the other doesn't complain. If I suddenly decide to start keeping the data in XML, I should be able to swap out the data layer, and the BL is none the wiser.

-tg

[leinad31]

I guess it also depends on how your organization is organized, manpower resources, size of the system, and such.

For small development teams and in-house development, additional layers is just additional work and maintenance. If size of system is manageable and integration is minimal, keeping things simple (BL in sprocs) would be the path of least resistance.

On the other hand, outsource providers or very large companies will lean towards more modular and layered design so they can support multiple platforms and such. They have the resources especially money to support this strategy.

[abhijit]

Here's a link (http://www.martinfowler.com/articles/dblogic.html)to an interesting article.

[techgnome]

I'm not sure what your point with the article is (which is 7years old and should probably be re-visited for technological reasons) ... Like most comparison papers, it glosses over the complexities of real life and inserts its own simplistic paradigm. The coding does some simplistic selections, aggregation and joining of data in multiple tables. But none of it is truly BL. It's data extraction and analysis, something that leans heavily towards SQL.

Try something like this for instance: a six-part alphanumeric code, each part separated by a dot. The whole code needs to be stored in tableA. Then each part broken down, stored in individual records in tableB, along with a sequencing number (so that part 2 is before part 3 and 4, but after part 1). And a masking code needs to be generated for each part (so that if part 2 is 3 characters, when it's reassembled, it will still be 3 characters long -- BUT I can edit the mask and make part 2 a length of 4, so in re-assembly the 3character code needs to be properly padded according to the mask, and regenerated with a length of 4). Now do it a couple hundred times. Per user, being accessed remotely from multiple locations at the same time. THAT is business logic. THAT's the kind of stuff that should NOT be in SQL. SQL Server isn't exactly efficient when it comes to string manipulations ... but VB is... so is C/C++ and C#.

The linked article took an overly simplistic view and if taken as guidance, would have you put your BL into SQL. Which would be a disservice for performance as well as asking your data storage and retrieval system to do something it shouldn't be doing.

-tg