I agree that we should put CRUD methods in a data access layer， However, in my current project I have some issues.
It is a legacy system, and there are quite a lot CRUD methods in some concrete manager classes.
People including me seem to just add new methods to it, rather than reuse the existing methods.
Because
- We don’t know whether the existing method is what we need
- Even if we have source code, do we really need read other’s code then make decision?
- It is updated too quickly. Do not have time get familiar with the DAO API.
Back to the question, how do you solve that in your project? If we say “reuse”, it really needs to be reusable rather than just an excuse.
The main problem would seem to be that the legacy interfaces are not understood and not trusted. It’s not possible to solve this problem by ignoring it – and adding more members ad-hoc is actively making it worse.
The bottom line is that interfaces to your classes should be clear, small, trusted, well-documented, and ideally only about a single responsibility (refer to the Single Responsibility Principle).
Techniques like refactoring can be used to move towards that ideal goal. Remember: it will take conscious effort to improve the situation.
Assuming that your organization has the right for to access and change the code, the right thing to do is to:
-
Plan for missing activities in your project such as: source control, locating missing code, learning current system, etc.
-
Find the source code for the system you are changing. Unless the application is trivial, it is most probably going to be useful specially if it is still in production.
-
Study the schema and the source code well and plan to re-use. You may find information you don’t know such as filed dependencies that are not obvious or special business rules.
-
Don’t write new code that is like the old code unless there is a major issue with the old code. You need to have a clear policy as why there are 2 different classes for Customer for example, otherwise, maintenance and testing will be hell.
I don’t understand your point (#3).
The only valid excuses to not re-use existing system’s code, INMO, is if you are migrating the system to use a new framework or can’t access the code for a technical or legal reason. A system must have internal order and proper structure, it can’t be a quality system if it looks like a college student’s room!
In a DAO you may return 3 columns from table A, joined with 2 columns from table B, etc. Maybe 4 tables are touched in a single transaction. It will be a necessity to create a new method for new functionality, even on existing tables. The possible permutations are endless. It is not possible to cover every database interaction with generic CRUD methods.
Actually it’s possible to cover every interaction with generic CRUD, but it would be like forcing a circle through a square shaped hole.
Usually some sort of framework provides generic CRUD access to the tables. The methods are often designed for working on 1 record at a time. If you fall within this scope, then use the generic CRUD methods. But you wouldn’t want to use these methods to update 5 million rows as they would literally perform 5 million separate updates. (they also tend to redundantly update all columns of the row, whether edited or not causing locking issues). You cannot use them for transactional functionality if they are non-transactional.
Just identify when to use the generic CRUD methods vs custom methods.