Business Rules Tier

[RobDog888]

What would be the proper use of a Business Rules Tier?
In other words what code logic would one place in a BR dll?

Thanks in advance for any help.

[Calibra]

Originally posted by RobDog888
What would be the proper use of a Business Rules Tier?
In other words what code logic would one place in a BR dll?

Thanks in advance for any help.

You would put the same logic in there as you would put in an 2 tier application regarding to the business rules you would use in an 2 tier app.

The main reason to choose for an 3 tier app instead of an 2 tier-app is when you have an very big company with lot's of user's then you would not have to update so much computers with new busines rules (when for let's say the VAT would change) or when you work across multiple states you wouldn't need to compile differnet user apps, but just different BR DLL's (or activeX's).

So what code you put in there is entirly depend on youre app and company needs.

But an small example would be :

Main office with SQL server in New York
Sales in California
Sales in Florida

All users have the same App, but VAT, taxes etc etc are calculated in 3 different DLL's so when Florida changes it's sales taxes, youy would only need to update the DLL's in florida and not compile an new App or change the production SQL server (not really popular if you what i mean)

[RobDog888]

My app is not that big. Its only used in house by about a dozen users.
I wanted to optimize it by re-writing it in .NET and fix all the
design flaws. Right now everything is inside the exe.

So for the client side exe it should only have control validation
and navigation between forms type of code?

I'm still struggling on understanding n-tier. I gues after I finish my
first one it will get easier.

Thanks.

[Calibra]

Rule of thumb that i use,

< 10 users = 2 tier (yes an app with for example an acces backend is considerd 2 tier)
> 50 users = 3 tier app

3 tier
User tier is for displaying/inputting data
BR tier for validating, calculating the Data and user rights for the data
Data tier for storage


In an 3 tier app user tier and BR tier can be on the smae comp OR BR tier and Data tier on on comp (which would prob be better, so you would only have to update 1 comp to apply new BR rules)

P.S. Using an BR tier to acces an sql server can cut cost dramaticly cuz you would only need 1 license for SQL instead of an license for every single SQL user.

[RobDog888]

This is a second thread from the Data Tier thread I had before.
So your saying to write a dll for both db access and br?

[Calibra]

Originally posted by RobDog888
So your saying to write a dll for both db access and br?

If this would give you the best design benifits then yes, otherwise combine them, it's completly depended on youre needs.

But the bigger the user number, the smaller you want youre components

But in youre case (small user number) the most logical would be to combine the acces DLL and BR DLL into 1 DLL.

so that would give you :
1st tier - User tier (interface. data input/output etc etc)
2nd Tier - comm. with DB (inc. BR in this component)
3th Tier - Data Storage (acces DB)

Maybe it's an bit clearer now, BR isn't actually an Tier so you are free to place them in any tier you wish.
With an SQL server as backend is not uncommen to place the BR as stored procedures in the SQL server it self (not my favorite though).

[RobDog888]

Getting a little clearer now, but would a BR function be something
like pre-validating of data entry, validation of all required fields
are entered before a new record was added, etc.

Currently they are all in the client side exe.

[Calibra]

Originally posted by RobDog888
Getting a little clearer now, but would a BR function be something
like pre-validating of data entry, validation of all required fields
are entered before a new record was added, etc.

Currently they are all in the client side exe.

yes an BR could be checking if an user enters an valid Tax amount for example, or enters an valid discount etc etc.

[RobDog888]

That seems like it would always have to be updated if we add
a new control or add items in a combo just like needing to update
the exe.

Unless there I can write some dynamic function/validation in the
BR dll. Then if the rules need changing then I only have to change
the BR dll. right?

Thanks.

[Calibra]

Now you got it, you should put the BR in the place you can update them with as less as possible work.

And so it differs from project to project where you should put your BR

[RobDog888]

Thanks Calibra. I will be starting to write the BR code after I start
on the Data Service tier. Still not sure how to do it. even from all
the responses from my Data Service Tier thread. :(

[szlamany]

Originally posted by Calibra
With an SQL server as backend is not uncommen to place the BR as stored procedures in the SQL server it self (not my favorite though).

We choose the SPROC layer for business rules in three large scale enterprise apps we have produced.

One is a school district - over 1000+ users - student administrative system. Other is a municipality - payables, receivables, general ledger, payroll - dozens of users.

Last one is a labor union - about 40 users - but really large data - 3 million row health claim tables, hours contribution tables.

This is our first venture into PC/SQL world - we came from mainframe/VAX-VMS/BASIC world.

In three years of development we have completed an extremely lightweight user interface - nearly 100% free of business logic. It self binds to the SPROCS in the MS SQL database (using homegrown logic here).

This single front-end is common to all three customers.

All business rules go into SPROCS. They fire as a user walks through a row in a flex grid for instance, filling columns - stuff like that.

We update the UI .EXE only when new features are required (for one of the three customers - since they all share the .EXE) or when a bug is uncovered.

When a customer requires a change to BR - it's a simple SPROC update - they don't even have to exit the UI - the SPROC change is realized immediately.

I've had customers call and say "it won't allow me to override the budget for this type of GL account" - and I say, "hold on - I'm changing that SPROC now - ok, done - press ENTER again, should work now." We calculate student GPA and RANK in CLASS in a single SQL QUERY - in a SPROC - very neat (used to be dozens and dozens of lines of BASIC code). We adjudicate medical claims in a SPROC - again used to be pages and pages of BASIC code.

We truly appreciate the SQL ability to BEGIN TRAN and ROLLBACK in a SPROC. We run "pre-calc" payroll registers - and rollback after the RECORDSET is returned for the payroll reports. All kinds of reports ask "Commit (Y/N)" - loading NURSE attendance into office attendance, loading bank recon data - so many places.

After 20 years of mainframe development with shareable libraries and 400+ different user programs - we are very satisfied with this technique. On the mainframe we had a proprietary DB that we used - so we were already familiar with having BR functions that could be imbedded within the DB itself.

Now that we have 2 of the 3 customers fully installed and the 3rd 50% there - we are going to start work on making the UI layer actually read the "text box" and "flex grid" locations on each form from a SQL table itself. This will reduce the UI app from 30+ forms to a single form that will clone itself for each form loaded (actually we will have three forms - one for each of our common resolutions). This should shrink the 2mb UI .exe way down in size.

Then we will turn it into VB.Net (it's VB6 now)...

[Calibra]

Originally posted by szlamany
We choose the SPROC layer for business rules in three large scale enterprise apps we have produced.

One is a school district - over 1000+ users - student administrative system. Other is a municipality - payables, receivables, general ledger, payroll - dozens of users.

Last one is a labor union - about 40 users - but really large data - 3 million row health claim tables, hours contribution tables.

This is our first venture into PC/SQL world - we came from mainframe/VAX-VMS/BASIC world.

In three years of development we have completed an extremely lightweight user interface - nearly 100% free of business logic. It self binds to the SPROCS in the MS SQL database (using homegrown logic here).

This single front-end is common to all three customers.

All business rules go into SPROCS. They fire as a user walks through a row in a flex grid for instance, filling columns - stuff like that.

We update the UI .EXE only when new features are required (for one of the three customers - since they all share the .EXE) or when a bug is uncovered.

When a customer requires a change to BR - it's a simple SPROC update - they don't even have to exit the UI - the SPROC change is realized immediately.

I've had customers call and say "it won't allow me to override the budget for this type of GL account" - and I say, "hold on - I'm changing that SPROC now - ok, done - press ENTER again, should work now." We calculate student GPA and RANK in CLASS in a single SQL QUERY - in a SPROC - very neat (used to be dozens and dozens of lines of BASIC code). We adjudicate medical claims in a SPROC - again used to be pages and pages of BASIC code.

We truly appreciate the SQL ability to BEGIN TRAN and ROLLBACK in a SPROC. We run "pre-calc" payroll registers - and rollback after the RECORDSET is returned for the payroll reports. All kinds of reports ask "Commit (Y/N)" - loading NURSE attendance into office attendance, loading bank recon data - so many places.

After 20 years of mainframe development with shareable libraries and 400+ different user programs - we are very satisfied with this technique. On the mainframe we had a proprietary DB that we used - so we were already familiar with having BR functions that could be imbedded within the DB itself.

Now that we have 2 of the 3 customers fully installed and the 3rd 50% there - we are going to start work on making the UI layer actually read the "text box" and "flex grid" locations on each form from a SQL table itself. This will reduce the UI app from 30+ forms to a single form that will clone itself for each form loaded (actually we will have three forms - one for each of our common resolutions). This should shrink the 2mb UI .exe way down in size.

Then we will turn it into VB.Net (it's VB6 now)...

Nice, but the reason i don't like the BR in the Data Backend is because i like to maintain an databackend indepency as much as possible, i.o.w. it should be easy to switch between SQL server, Oracle etc etc.
Second what if youre app runs in multiple country's with different BR?, then i would prefer the BR in the 2nd Tier, keeping the UI for every user the same an the Database server as uniform as posible.

[szlamany]

Originally posted by Calibra
Nice, but the reason i don't like the BR in the Data Backend is because i like to maintain an databackend indepency as much as possible, i.o.w. it should be easy to switch between SQL server, Oracle etc etc.
Second what if youre app runs in multiple country's with different BR?, then i would prefer the BR in the 2nd Tier, keeping the UI for every user the same an the Database server as uniform as posible.

I can appreciate those reasons...

We have definitely signed on to an MS-pure solution. Our customers almost demand it (they pay the $$'s - so what am I to say!). I can see how that is limiting, but on the other hand we are free to use non-standard SQL (MS T-SQL specifics) - so I'm lured into the web...

As for other languages - once we sell our packages to all the school districts in the US and Canada (we already support 6 digit alpha-numeric zip codes!) we can work on the other language edition :D

But actually, on the VAX software we have already experienced hundreds of school districts and rely heavily on "control" tables to alter functionality - we hate to hardwire business rules in general - so we go the extra step of making everything flexible and configurable.

If you could only imagine all the different flavors of honor roll and GPA calcs's I've experienced since 1980...

[Dave Sell]

Originally posted by Calibra
Nice, but the reason i don't like the BR in the Data Backend is because i like to maintain an databackend indepency as much as possible, i.o.w. it should be easy to switch between SQL server, Oracle etc etc.
Second what if youre app runs in multiple country's with different BR?, then i would prefer the BR in the 2nd Tier, keeping the UI for every user the same an the Database server as uniform as posible.
Calibra, in your opinion, the approach szlammy described, does it seem to you that his bus rules are in the same tier as his data tier?

[Calibra]

Originally posted by Dave Sell
Calibra, in your opinion, the approach szlammy described, does it seem to you that his bus rules are in the same tier as his data tier?

Yup, SPROC = Stored Procedures, routine's housed in an Database, so yes then szlammy's BR are house in the Data tier

[szlamany]

I was waiting for that response...

I guess I'm not a purist - I consider the SPROCS to be a different layer than the data itself. I'm so radical!

I even consider USER-DEFINED FUNCTIONS to be a different layer than the data itself.

The fact that it's all in "one-suitcase" makes server management and disaster recovery neat and simple.

[Dave Sell]

Originally posted by szlamany
I was waiting for that response...

I guess I'm not a purist - I consider the SPROCS to be a different layer than the data itself. I'm so radical!

I even consider USER-DEFINED FUNCTIONS to be a different layer than the data itself.

The fact that it's all in "one-suitcase" makes server management and disaster recovery neat and simple.
I agree that you can consider your SPROCS in a different layer, but I think they are in the same tier. IOW, a Tier can consist of layers.

This probably begs the question, how do you define a tier?

[szlamany]

Well - SPROCS are truly an odd item in SQL.

Nothing else in the database is parameterized - VIEWS and TABLES and what not are all "basic data".

SPROCS, being parameterized - by that distinction, separate themselves from the data. There is "flow-control" - they are actually programs in and of themselves - right?

You can even break all the rules and use cursors and loop through data. They interact with the data - they are not the data - in my opinion.

I personally do consider them my "business-tier". We actually only allow ADO to talk to SPROCS from the UI - there is no table access allowed.

To quote a prior post here...

1st tier - User tier (interface. data input/output etc etc)
2nd Tier - comm. with DB (inc. BR in this component) ADO does this in concert with SPROCS
3th Tier - Data Storage (acces DB)

[Dave Sell]

Originally posted by szlamany
Well - SPROCS are truly an odd item in SQL.

Nothing else in the database is parameterized - VIEWS and TABLES and what not are all "basic data".

SPROCS, being parameterized - by that distinction, separate themselves from the data. There is "flow-control" - they are actually programs in and of themselves - right?

You can even break all the rules and use cursors and loop through data. They interact with the data - they are not the data - in my opinion.

I personally do consider them my "business-tier". We actually only allow ADO to talk to SPROCS from the UI - there is no table access allowed.

To quote a prior post here...

1st tier - User tier (interface. data input/output etc etc)
2nd Tier - comm. with DB (inc. BR in this component) ADO does this in concert with SPROCS
3th Tier - Data Storage (acces DB)

I think the reason I am leaning toward the opinion that SPROCS do not qualify as a tier is because I expect the ability to un-hook it from the datastore, and re-hook it to a different datastore.

Clearly, your SPROCS are inseperable from your RDBMS. Also note I am not criticizing your design approach; I rather like it. I'm just concerned with discussing things that may or may not qualify as a tier.

[szlamany]

Originally posted by Dave Sell
I think the reason I am leaning toward the opinion that SPROCS do not qualify as a tier is because I expect the ability to un-hook it from the datastore, and re-hook it to a different datastore.

Clearly, your SPROCS are inseperable from your RDBMS. Also note I am not criticizing your design approach; I rather like it. I'm just concerned with discussing things that may or may not qualify as a tier.
I must agree with you - in order to constitute a true 3-tier client server model, the middle tier must be independent of the client and server applications. It will generally reside on the same machine as the server. (quote from Professional VB6 Databases (with VB, ADO, SQL Server and MTS) - Multi-tier Database Programming - WROX publications - Charles Williams).

When we started this project three years ago we easily spent 6 months just researching architecture. Having come from a proprietary DB on the VAX (written in an assembly language) we could not avoid the pleasure of using ADO to talk to 4GL SPROCS that did all the business logic. The only programming that we've done in VB has been user interface - and that's time consuming enough. Having to create some COM technique to pass data back and forth to the business tier when ADO with PARAMETERIZED SPROCS was already available was just too tempting to ignore.

If MS SQL offered an "engine" to run SPROCS that was separate from the "engine" running the low-level data access, then that middle-tier rule would be realized - right?

[Calibra]

Originally posted by szlamany
I was waiting for that response...

I guess I'm not a purist - I consider the SPROCS to be a different layer than the data itself. I'm so radical!

I even consider USER-DEFINED FUNCTIONS to be a different layer than the data itself.

The fact that it's all in "one-suitcase" makes server management and disaster recovery neat and simple.

FIrst up, there are no right or wrong design choices, just consequentes,
Second no SPROCS are not considered an separate Tier, layer maybe, but it is still the Data tier that houses them.


2nd Tier - comm. with DB (inc. BR in this component) ADO does this in concert with SPROCS

Doesn't have to be ADO, can be ODBC or any one other, maybe one that can't handle SPROC's and then, how are you gonna implement your BR then, as i said, i always strive for an solution where it doens't matter if it's SQL sever, Oracle, DBase or whatever obscure database backend is running.

As soon as youre product forces an customer to change his database also, you product becomes less interesting, customers want new software, not an new database. (useally that is)

[Dave Sell]

Originally posted by szlamany
If MS SQL offered an "engine" to run SPROCS that was separate from the "engine" running the low-level data access, then that middle-tier rule would be realized - right?
If said "engine" was seperable from MS SQL Server, where you could use a different RDBMS, and this engine could run on a different machine/network from the RDBMS, then I would consider it a true tier. I think.

Personally I am not whole-heartedly convinced that it is even possible to abstract a modern RDBMS into a true backend DB tier anyway. I am willing to debate this.

[szlamany]

Originally posted by Calibra
FIrst up, there are no right or wrong design choices, just consequentes,

As soon as youre product forces an customer to change his database also, you product becomes less interesting, customers want new software, not an new database. (useally that is)

I agree - there is no right or wrong - but there are consequences. After spending 20+ years doing Digital VAX/VMS programming to only have the 2nd-largest hardware company evaporate one day and the best oeprating system (VMS) just disappear was quite a stressful experience. We held onto our largest customers - and watched as they all decided that MS was the only place to go next. No ORACLE (I wouldn't have minded) - no IBM DB4 - just straight old MS. And I must admit that MSDE (free-SQL) and interoperability with other OFFICE tools is very nice (on the surface) - and that's what the customers look at. I was a diehard anti-MS person 5 years ago...

Originally posted by Dave Sell
Personally I am not whole-heartedly convinced that it is even possible to abstract a modern RDBMS into a true backend DB tier anyway. I am willing to debate this.

On our VAX systems we developed our own RDBMS - since we were both DB developers and APP developers when a function was required for business logic, it went right into the RDBMS - that allowed our UI tools and REPORT WRITER tools to access the business logic without any changes.

With that said, I'll take up the side of RDBMS not being able to be a true backend DB tier.

[techgnome]

I'm going to chime in with my $0.03 worth, because I hate to see terms misused.

For starters: Having BR in the database scares the crap outta me. BUT, I can see why. Doesn't mean it doesn't scare me.

Secondly, there is a difference between mulit-tiered apps and multi-layered apps. Separating your UI from your BR from your DA but leaving them on the same machine is layering your app. But technically it is still 2-tiered (unless the DB sits on that same machine, in which case, it then flattens into a single tier.) Tiering an application is more that separating the code into distinct components, it also involves physically separating them onto multiple servers. Ideally, a n-tier architectured app would have a SQL Server (data store), a data access server, a BR server, and the client (which holds the UI). Moving any two of those onto the same server shrinks it to a 3-tier. Sometimes you may also have a validation server. The idea is that if a BR rule needs to be changed, it is changed in one spot on the BR server, and it does not affect any other part of the application & in fact, the rest of the application isn't even aware that the replacement even took place. MTS & COM & COM+ is what made this all possible.

Now it's Web Services. You make a call to a publicly accessable Web Service, it sends the request to another (internal) server that validates it, sends it on for data retrieval, gets the returned data, sends that back through the validator, which then sends it back to the web service, and ultimately back to the user.

Multi-tiering isn't an easy job, nor is it a good idea for smaller apps. However, layering, or the abstraction of the components into layers is a different thing, much easier to do, and makes things easier at later times. I wouldn't want to discourage you from what you are attempting (I do it on every project I work on) I just want to make sure all the right terms are used properly. Now, how do I know all this? It's the part of the MCSD test I blew big time. :bigyello:

Tg

[techgnome]

Originally posted by Dave Sell
Personally I am not whole-heartedly convinced that it is even possible to abstract a modern RDBMS into a true backend DB tier anyway. I am willing to debate this.

As a data store, if it sits all by itself and does not contain any BR, validation, or direct interaction, I'd argue that it is a valid DataStore Tier. Otherwise it is simply a part of the data access layer (see my previous post regarding that.).

Tg

[Calibra]

Originally posted by techgnome
I'm going to chime in with my $0.03 worth, because I hate to see terms misused.

For starters: Having BR in the database scares the crap outta me. BUT, I can see why. Doesn't mean it doesn't scare me.

Secondly, there is a difference between mulit-tiered apps and multi-layered apps. Separating your UI from your BR from your DA but leaving them on the same machine is layering your app. But technically it is still 2-tiered (unless the DB sits on that same machine, in which case, it then flattens into a single tier.) Tiering an application is more that separating the code into distinct components, it also involves physically separating them onto multiple servers. Ideally, a n-tier architectured app would have a SQL Server (data store), a data access server, a BR server, and the client (which holds the UI). Moving any two of those onto the same server shrinks it to a 3-tier. Sometimes you may also have a validation server. The idea is that if a BR rule needs to be changed, it is changed in one spot on the BR server, and it does not affect any other part of the application & in fact, the rest of the application isn't even aware that the replacement even took place. MTS & COM & COM+ is what made this all possible.

Now it's Web Services. You make a call to a publicly accessable Web Service, it sends the request to another (internal) server that validates it, sends it on for data retrieval, gets the returned data, sends that back through the validator, which then sends it back to the web service, and ultimately back to the user.

Multi-tiering isn't an easy job, nor is it a good idea for smaller apps. However, layering, or the abstraction of the components into layers is a different thing, much easier to do, and makes things easier at later times. I wouldn't want to discourage you from what you are attempting (I do it on every project I work on) I just want to make sure all the right terms are used properly. Now, how do I know all this? It's the part of the MCSD test I blew big time. :bigyello:

Tg

Tech. speaking you are right (i didn't blow that part of MCSD :D ), but this way off working was devised in an time where server power was less availeble and nearly not as cheap as nowadays, so they decided that it was an good idea to split tasks between comps so they could use less expensive servers (and dumb user comps).
But as server power increased (and software demands stayed more or less the same) it really doesn't matter that the 2nd and 3rd tier are located on one server.
I personally like to think als the tiers not computer related anymore but more as an abstract way of thinking.
Only really big applications nowaday really benifit from completly separated tiers, and this mainly due to the fact that you could have more than one Databackend, Data retrievel en BR server in youre system.
Any application which doesn't need load balancing, doesn't have to have split servers for every single tier.

[Dave Sell]

Regarding the issue of whether or not a Tier must be on its own machine in order to be considered a true tier:

No. A true Tier does not have to be on its own machine in order to be considered a true tier.

However, it is a requirement that it have the potential to be removed onto its own machine and be truly stand-alone in order to be considered a true tier.

Where it is doesn't affect what it is.

[RobDog888]

Guess you guys have been busy while I was out.

I read all the posts and this really helps allot. As soon as I get
the database designed I will be posting back in a new thread.

Until then can someone show an example of a BR function/procedure.

Thanks all.