Where to build business logic in DB or web service & how ?
-
Hi,
It is regarding some issues on web application using ASP.NET and SQL2k. Some of my colleague argue that business logic should be build inside the DB while other argue it should be build in our web service server. I am confused which one is the better and correct way to go. Any method to determined where to build my business logic and how to build it. Next, how to make business logic build in flexible so that we can change the business logic on the fly without any compilation, just changing the logic either by script or logic save in the DB. Anyone with expertise in this area, please kindly advise and guide me. Thank a lot.
-
There is no one answer to this question. Any properly designed database incorporates a great deal of business rules in it. However, there will always be some business logic that needs to be performed by the application. A quick example is a system that tracks sales by sales-person. The data on each sale obviously needs to be contained in the database, but the logic that uses that data to rank sales-people may be best left to the application.
Generally, the basic data and foundational rules i.e. the relationship between parts, suppliers, sales and customers should be captured in a good database design, but how you use that data is left up to the applicaiton. This way the data is what it is, and multiple applications can access it and use it to satisfy different ends.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
I agree with dcpeterson on there being more than one answer. Where does the strength of the team lie, what channels will be using the business logic layer, can more than one layer be cleary defined and would doing so be advantageous.
I'd advise on building in flexible business logic to try to follow oo programming ideas of objects and properties. Meaning if it can be male or female don't hard code it ander remember the option other.
Everett Wilson
ewilson10@yahoo.com -
Just to clarify, the business rules that define what the data is should be in the database. The business rules that define how the data is used for a specific purpose belongs in the application.
To put it another way, the database should accurately describe a particular business reality, the application puts that information to use. Herein lies the basic problem with Everett's unqualified suggestion to use oo programming ideas. OO ideas do not belong in the database, OO is concerned with what things DO, a database is concerned with what things ARE. OO is also strongly hierarchical, using "is a" logic whereas relational databases are capable of dealing with "has a" logic. Hierarchical structures are not suited to general data management.
So, by all means, use oo principles in your application, but do not get trapped into thinking that tables are "objects" etc...
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
I've been thinking about this a lot - one of my main problems is that there is a lot of business logic in our forms code - it doesn't belong there, no way, not ever.
In a nutshell the problem is that a lot of the conclusions that my business logic comes to is hidden in my applications code. This stops me from reusing it elsewhere (for example, I have a planning application which calculates planning time, I am trying to integrate with this from another app, I can't because some of the algorithms are in the application, if they were in stored procedures then I could just tap in whenever.
I've also rewritten some code in .NET, to take issue with DC the conclusion I came to was that if you're using OO forms then you should implement views and stored procedures to abstract your relational data into an OO framework. This makes life much easier.....
Just my half p.
Rich
-
dcpeterson is right again. We're definitely not in oo land.
Richard I'd suggest he's onto something if load on the server is not an issue and he really can define a business layer on the SQL Server. One of the big projects I dealt with this last year had added value information being pumped out to four different interfaces, including the rather slow MS Access (plus .net, Cold Fusion, and Oracle).
At the same time, though, if the programming unit had the skill to build a business logic layer to handle the variuos calculations that could be used by various applications that would've been great. But their strengths lie elsewhere and playing to strengths is what it comes down to.
Everett Wilson
ewilson10@yahoo.com -
Try these articles:
http://www.devarticles.com/c/a/ASP.NET/Boosting-Your-.NET-Application-Performance/1
or
http://www.15seconds.com/issue/011219.htm
The "DataTier" should only do things like
Return DataReaders
Return DataSets
Return Scalars
Execute Stored Procedures, by sending parameters in. It should not really "discern" those parameters, and have forks in the code to do different things because of the parameters.
Your db should do what a DB is designed to do.
SELECT data
INSERT data
UPDATE data
DELETE data
or, the other way to say it: CRUD ...Create, Read, Update, and Delete.
"Get in, get out" is the philosophy I adopt.
Stuff like
if @empstatus = 1
update emp set salary = 100000 where empid = @empid
this kind of stuff does not belong in the database. that's "business logic".
Once in a while, there might be a reason to put some BL in the database. But 99.9% of the time, you don't want to do this.
By writing a correct DataLayer object (remembering that all you return are DataReaders, DataSets and Scalars), you theoretically could swap out your database, with minimal impact.
Even if you 99.9% sure you won't do this, its not a bad standard to live by.
The .1% (1/10th) is if you can get a SIGNIFICANT performance boost by crossing over the boundries.
Keep in mind, that writing bad tsql isn't an excuse for this .01% of the time. Bad cursors, misused/unused indexes, overloading on the triggers, is not a good excuse to break the rule.
(I've written 1 cursor in the last 5 years, and only wrote it because I tried for 3 days to it another way.)
(Aka, there is almost always a way to write non cursor code. esp with the advent of UDF's).
That's my take. I've been in the game for 10 years now. And early on, I wrote alot of crap and way too much BL in the database stored procedures.
Good software development and RAPID software development are not the same thing.
Sometimes the goals will dictate things differently.
///EDIT
I thought of a simple thing where I might break the rule.
You have a "uspUserLogin", where you check to see if the user's name and password check out.
Lets say I find the user, with the credentials.
I'd do something like
Update UserInfo Set LastLoginDate = GETDATE where UserUUID = @UserUUID
to avoid a second trip to the database, just to update this somewhat trivial information.
-
You seem to be advocating using the database merely as a "persistence mechanism" for the application. In reality it is applications that come and go, while data tends to persist and be used by multiple applications.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
"Data tends to persist".
That's the point, I think. It needs to persist.
That's what DB are used for. Persisting data effectively.
..
This image (from one of the links I posted) has a good description I believe.
https://www.sqlservercentral.com/Forums/Uploads/image-unavailable.png
-
By saying "data persists" I meant that data tends to live much longer than applications. Furthermore data is more important than applications. That chart, and countless others drawn from an application development perspective, tend to view the database as merely a "persistence mechanism."
That view is understandable, but wrong. If applications just need a place to stick data and retrieve it, you should be using file based data storage, not a DBMS.
One of the core reasons for the existence of DBMSs is the idea of data independence. If the business rules that define what the data is reside in the application, there is no data independence.
A properly designed database does MUCH more than serve as a bit bucket for a given application, and only those who are ignorant of history and data management fundamentals would suggest otherwise. It's a bit like saying that an F-18 is a place to store jet fuel.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
Ok... you have your opinion, I have mine. The poster can determine their own opinion, I'm just posting information.
My textbook for my Grad Class at NCSU
http://www2.acs.ncsu.edu/reg_records/crs_cat/CSC.html#CSC540
was this book:
http://www.amazon.com/gp/product/0321122267/102-1404998-1004146?v=glance&n=283155
Here is a summary I found:
http://www.cc.gatech.edu/classes/AY2002/cs6400_spring/FILE1_revised_wf.pdf
4. Advantages of Using a RDBMS.
- Controlling redundancy in data storage and in development and maintenence efforts.
- Sharing of data among multiple users.
- Restricting unauthorized access to data.
- Providing multiple interfaces to different classes of users.
- Representing complex relationships among data.
- Enforcing integrity constraints on the database.
- Providing backup and recovery services.
- Potential for enforcing standards.
- Flexibility to change data structures.
- Reduced application development time.
- Availability of up-to-date information.
Or you can search google for this:
Those things are what makes a DB something better than a file ("using file based data storage").
Outside of enforcing integrity constrainsts, I don't see alot of BL in the description of what a RDBMS is.
I'm not arguing anymore. I hold to my opinion.
Good luck Vladimir, with whichever path you choose.
-
In my OPINION the role of the database has taken a real hit with MS pushing their version of n-tier. Keeping in mind the uppercase word above, if you delve deeper into the theory design books you will find that tiers can exist everywhere. If you're in a .NET only environment, you feel comfortable about the presentation layer not chaning, and/or the unit has the expertise or ability to learn, then go to your strength. But don't do it just because some experts say so.
As for this is what Prof X uses: I know one respected research professor who teaches MS Access isn't a database (I'd love to audit his class). There's a profound truth there but it sure stinks teaching his students about the real world.
Everett Wilson
ewilson10@yahoo.com -
Hi,
my system uses a third-party application to access and update the data. I write as much of the business logic as I can in SQLServer as SPs and UDFs. Recently the third-party application company went into administration. I am putting my trust in Microsoft.
David
If it ain't broke, don't fix it...
-
- Restricting unauthorized access to data.
- Providing multiple interfaces to different classes of users.
- Representing complex relationships among data.
- Enforcing integrity constraints on the database.
- Potential for enforcing standards.
- Reduced application development time.
Those all sound like business logic to me...
However, any list that leaves off data independence is woefully incomplete. Also, have you given any thought to how DBMSs reduce application development time? The primary reason is that many of the fundamental business rules are encapsulated in the structure of the database.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
Access ins't a database, to be charitable, it's a database management system. That isn't just a quibble, but leaving that aside, Access doesn't really even qualify as a SQL DBMS, much less a Relational DBMS. It does have some of the charateristics of a DBMS, but totally lacks transaction support among other things... This is the same problem MySQL had until recently.
Of course, SQL Server, DB2, and Oracle are not truly Relational Database Management Systems either.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply