Is two-tier a reason to use stored procedure rather than OOD?
-
I am a OOD applier, I am working on a company that they provide two-tier (application-database) solution, I reviewed most of existing source code that most business logic are located in stored procedure, I feel that is not a good idea, and now, some colleague want to change because of difficult to maintenance but because it need change the thinking approach so some colleague become anti-OO. Because of company solution is two-tier, is stored procedure a good approach in this environment? P.S. Because of the vender lock-in pattern, the provided solution at least contain client application tier.
-
I am a OOD applier, I am working on a company that they provide two-tier (application-database) solution, I reviewed most of existing source code that most business logic are located in stored procedure, I feel that is not a good idea, and now, some colleague want to change because of difficult to maintenance but because it need change the thinking approach so some colleague become anti-OO. Because of company solution is two-tier, is stored procedure a good approach in this environment? P.S. Because of the vender lock-in pattern, the provided solution at least contain client application tier.
Putting in all Biz Logic in Stored Procedure is not a good approach. Data Filtering logic should be put in Stored Procedure. Whereas the Biz Logic and other data processing logic should be in Biz Layer. I can understand your situation. It is not going to be a easy task of changing peoples mindset overnight. However, slowly slowly once the developers sees the benefits of layered architecture, they are going to change. My suggestion for you is to start coming up with Biz Components and changing stored procedures and then get into layered architecture for your application.
-
I am a OOD applier, I am working on a company that they provide two-tier (application-database) solution, I reviewed most of existing source code that most business logic are located in stored procedure, I feel that is not a good idea, and now, some colleague want to change because of difficult to maintenance but because it need change the thinking approach so some colleague become anti-OO. Because of company solution is two-tier, is stored procedure a good approach in this environment? P.S. Because of the vender lock-in pattern, the provided solution at least contain client application tier.
I would disagree with Robin, but only because of the types of apps I am currently working on. I work mostly with batch processes, not transactional data. Therefore almost all our business logic resides in stored procs. We recently tried to move some of the logic back into a c# business layer but the performance was so abysmal we went back to stored procs. When working with large, batches on data then the database is the place for the business logic. If you are working on a transactional system, manipulating small amounts of data often then the business layer is the best option. Use the right tool for the job!
Never underestimate the power of human stupidity RAH
-
I would disagree with Robin, but only because of the types of apps I am currently working on. I work mostly with batch processes, not transactional data. Therefore almost all our business logic resides in stored procs. We recently tried to move some of the logic back into a c# business layer but the performance was so abysmal we went back to stored procs. When working with large, batches on data then the database is the place for the business logic. If you are working on a transactional system, manipulating small amounts of data often then the business layer is the best option. Use the right tool for the job!
Never underestimate the power of human stupidity RAH
Yes, I would definitely agree. Almost all of the time we put our business logic in a C# business layer. But sometimes there is no substitute, in terms of performance, for a bit of business logic in the stored procedures. Adam
-
I would disagree with Robin, but only because of the types of apps I am currently working on. I work mostly with batch processes, not transactional data. Therefore almost all our business logic resides in stored procs. We recently tried to move some of the logic back into a c# business layer but the performance was so abysmal we went back to stored procs. When working with large, batches on data then the database is the place for the business logic. If you are working on a transactional system, manipulating small amounts of data often then the business layer is the best option. Use the right tool for the job!
Never underestimate the power of human stupidity RAH