Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

how to avoid duplicate business logic Expand / Collapse
Author
Message
Posted Tuesday, October 2, 2012 9:33 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, February 4, 2014 3:37 AM
Points: 13, Visits: 76
Jayanth_Kurup (10/2/2012)
faster simpler better coding relies on moving business logic to the application layer. This is proven in many SOA implementations. The DB should stick to simple crud operations. The stored procedure is already a layer of abstraction between the application and data , however in your case the data itself changes so functions and views or even normal tables need to evaluated on a case to case basis.

A table that had a id column as PK may not id a PK once a new column is added or deleted. Try putting business logic in .NEt and app layer and if that doesnt work evaluate how it can be done within a proc.

a common mistake i have seen people make is trying too hard to make the business logic generic. Its not a good idea coz the business logic is constantly changing to meet new scenarios and managing all that change within the DB is a major headache.


I (guess I) understand... Up until now I tried to push the business logic up onto the database side (used to work on desktop apps, where changes to the BL could be made much easier if it was on the central server)
Then I guess for the future, we should try to separate the .Net side into display components and BL components, and focus on moving the BL that cannot be done using views to the .Net side (will not consider MVC or similar frameworks)
Post #1367122
Posted Wednesday, October 3, 2012 2:40 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Yesterday @ 7:48 AM
Points: 67, Visits: 433
You should bear in mind that moving business code to the application does introduce a possible loss of integrity. Does the application assure that every set of interdependent modifications are wrapped into transactions? If you need to change the physical database schema for performance reasons, will the application developer be able to incorporate this change easily in his code? I am both an application developer in .NET and a SQL Server DBA in several larger projects, and sometimes I favor .NET over stored procedures only because my fellow team members are not as familiar with SQL as I am.

Please think twice before you move business logic into the application. If it changes so often, how can any developer assure that 'old' data is still valid for the 'new' code? Who keeps track of all those changes to avoid any flaws an conflicts that might occur at the storage level inside the database? Many developers do not like foreign keys because they limit them severely in the way modifications on the data may be performed. But every 'relation' without a foreign key constraint is doomed to loose its integrity sooner or later.
Post #1367466
Posted Wednesday, October 3, 2012 5:48 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, February 4, 2014 3:37 AM
Points: 13, Visits: 76
All the developers are on both SQL and .Net, so we will not have those kind of problems.
Most of my concerns are regarding keeping everything in one place, and as clean as possible.

So, at the moment, I can say I'm confused :) I am aware of the speed gained by keeping everything in optimized stored procedures, but in the same time, I would like to maintain flexibility to make changes in BL faster, and with less modifications.
Post #1367584
Posted Thursday, October 4, 2012 8:55 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:37 AM
Points: 1,676, Visits: 4,781
norbert.manyi (10/3/2012)
All the developers are on both SQL and .Net, so we will not have those kind of problems.
Most of my concerns are regarding keeping everything in one place, and as clean as possible.

So, at the moment, I can say I'm confused :) I am aware of the speed gained by keeping everything in optimized stored procedures, but in the same time, I would like to maintain flexibility to make changes in BL faster, and with less modifications.

From what you've desribed, I think a view would provide the business logic encapsolation you need. As far as the employee table itself, it would be useful to have active_date, inactive_date, and status_code columns indicating the timeframe and reason for the employees status.
Post #1368487
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse