Hi Friends, I would like to know Which design pattern is better?MVC or DAO...What is there major difference? Which architecture uses stored procedures more?Is it better to implement business logic in SPs?
Is MVC better than DAO ... this is like asking whether gloves are better than shoes, they serve different purposes. Do you have some application in mind? If so, then you can do some investigation of your own and come back to this forum with some specific questions.
Originally posted by Akhil kumarS: Hi Friends, I would like to know Which design pattern is better?MVC or DAO...What is there major difference?
As Roger said, they do different things. MVC is a front end pattern and DAO is a back end pattern.
Which architecture uses stored procedures more?
Most architectures are agnostic once they get to the database technology. Your DAO could have a stored proc, Spring, Hibernate, plain JDBC, etc. The DAO isolates the rest of the code from this design decision.
Is it better to implement business logic in SPs?
It's not inherently better. Some would argue it is better; some would argue it is worse. I think it depends on the specific situation and who is calling the code.
I personally prefer keeping business logic in code - and keep most of the business logic out of the Stored procedure - because maintenance becomes hard and its difficult to test - unit wise.
Now when will I use a stored procedure? - to improve performance. Also lets say I have to update a value for a particular set of customers - and in a case of a million records doing it using stored procedure makes lot of sense. [ February 15, 2008: Message edited by: Venkatraman Kandaswamy ]
Originally posted by Venkatraman Kandaswamy: I personally prefer keeping business logic in code - and keep most of the business logic out of the Stored procedure - because ...
On most of the projects I work on we have something to do with a database. I've worked on projects where we used the database purely to store data, and where we had all business logic in Java code. I've also worked on projects where there was a separate team of database experts who designed and maintained the database. We were only allowed to access the database via stored procedure calls (we were not allowed to do queries, updates and inserts directly), so that the database people could control the access to the database and check integrity of the data in their stored procedures.
So, sometimes one approach works well, other times another approach.
I see MVC as how you design your application. A DAO is the proper way to have your application access your data, or persist the state of your application to the database. I often use the term MVCD, to emphasise how data access can be thought of a fourth, separate but important part of application development.
>>Which architecture uses stored procedures more?
Depends on how you implement it. A good DAO pattern allows implementations to be switched in and out seamlessly. With a good DAO pattern, the answer to 'which data access strategy should we use?' becomes "who cares".