Use Store Procedure or Not at All

st3fanus posted on Thursday, August 27, 2009

Hello I'm stefanus..
Before I share my question.. I want to say hello to everyone in this forum..
I'm indonesian... I'm newbie and beginner on using CSLA..
I have a little experience on development of real world software or project.. (just now graduate form my college).. I have finished one project (my first project and still the only one.. =) ).
I have developed that project using 2 layer model ( UI and Business Object based on Store Procedure )

I have got expensive cost on maintenance and a little flexibility..
And then i found a CSLA Framework ( Thanks a lot to RockfordLhotka =) )..
Now I have a hope to produce an application where i can focus on Business Object..

My fisrt question for introduction is :
I still confuse about the role of store procedure in CSLA ( Because if I just wrap Business Code in Business Object --> So What does happen if anyone can able bypass my Business Layer and go to my Database.. ) But if i create business code on database(StoreProcedure) too.. IT MEANS I HAVE MAKE DUPLICATION BUSINESS CODE ON Two Layer...


Note : Are there any indonesian members in this forum??

Thanks For ALL


GBU

JoeFallon1 replied on Thursday, August 27, 2009

Hi GBU,

Securing the database from unwanted intruders (including power users) is a completely different subject than using CSLA. As a developer sometimes you have control over the database and can enforce rules like - no one can do anything except SELECT against the tables. This prevents power users from modifying data through the back door. In a few environments you may be forced to allow people to do updates directly - bad idea but out of your control. In that case you should expose Stored Procedures for them to use.

But in most cases, you should be able to "force" people to use your application and UI which enforces business rules. In this way you do not have to write 2 APIs and you can choose to use SPs or not for data access.

HTH

Joe

 

JonM replied on Friday, August 28, 2009

I do the database work on a 5 person dev team. I prefer stored procedures over dynamic sql because it gives me more control over the database interface. It also makes refactoring changes much easier. Instead of searching 25+ vs projects for references to sql server I can simply search and correct the stored procedures. It also allows me as a sql server expert to keep other developers from submitting slow performing ad-hoc queries. Lastly, it makes it easier to unit test a database. I'm not sure how you would to this with adhoc sql.

SonOfPirate replied on Sunday, August 30, 2009

When discussing the role of stored procedures and how they "map" into an n-tier architecture, I often put sprocs in the same context as NHibernate or other ORM's.  While not directly creating or working with our objects, a stored procedure is intended to abstract the underlying data structure from the application developer.  By calling a stored procedure with a set of parameters and receiving data in an known structure (schema), we are able to simply code against this interface as another layer in our architecture.  Whether the data was found in one, two or ten tables, if complex joins, subqueries, etc. were required or if data was aggregated to form the results is completely abstracted from the application developer.  And, when you think about it, that is the job an ORM like NHibernate serves for us.  So, imho, it belongs in the same category when talking about n-tier applications.

 

st3fanus replied on Tuesday, January 19, 2010

Hi All...

JoeFallon1 
JonM
SonOfPirate

Sorry I'm just now say Thanks a lot of all your respond..
I'm appreciate that..

Thanks a lot


Stefanus