In almost every project I work on with a team, the same problem seems to creep in. Someone writes UI code that needs data and writes a data access method:
AssetDto GetAssetById(int assetId)
A week later someone else is working on another part of the application and also needs an AssetDto but now including ‘approvers’ and writes the following:
AssetDto GetAssetWithApproversById(int assetId)
A month later someone needs an asset but now including the ‘questions’ (or the ‘owners’ or the ‘running requests’, etc):
AssetDto GetAssetWithQuestionsById(int assetId)
AssetDto GetAssetWithOwnersById(int assetId)
AssetDto GetAssetWithRunningRequestsById(int assetId)
And it gets even worse when methods like GetAssetWithOwnerAndQuestionsById start to appear.
You see the pattern that emerges: an object is attached to a large object graph and you need different parts of this graph in different locations.
Of course, I’d like to prevent having a large number of methods that do almost the same. Is it simply a matter of team discipline or is there some pattern I can use to prevent this? In some cases it might make sense to have separate methods, i.e. getting an asset with running requests may be expensive so I do not want to include these all the time. How to handle such cases?
4
Syntax-wise, I’d create an intermediate query-building object with a fluid interface:
// all the basic, cheap to query fields
AssetDto a = AssetRetriever(asset_id).fetch()
// some common expensive fields
AssetDto a = AssetRetriever(asset_id).withOwner().withQuestion().fetch()
// numerous less common fields may not command dedicated methods
AssetDto a = AssetRetriever(asset_id).withFields("foo", "bar").fetch()
// Better yet, use an enum and enjoy static checking
AssetDto a = AssetRetriever(asset_id).withFields(F_OWNER, F_QUESTION).fetch()
I hope it’s obvious enough to implement. The only method that will actually touch the database is fetch().
1
When dealing with large object, this is really common. While adding new methods increases performance, it significantly decreases the maintainability. And again you need to choose between those two.
I suggest you have a method that returns (not necessarily the smallest) commonly used data, another that returns the whole object, and probably a few more for the most expensive resources.
Another approach is to have methods that return only the necessary fields of the object, like
AssetQuestions GetAssetQuestionsById(int assetId) or Owners GetAssetOwnersById(int assetId).
Along with this you need to establish some rules regarding retrieving data. For example, if someone needs 5 fields of the object, and there is an existing method returning 8, the existing method should be used.
5
I’ve been through this same problem recently and adopted the following solution:
Data access methods should get data only from a single resource (e.g., database table), and if the process needs related objects appended to the main object it should call for the method responsible for those respective objects.
This way if you need an asset with it’s approvers you should create a facade method wich join the objects.
Example:
public Class AssetFacade {
public AssetDto getAssetWithQuestionsByAssetId(int assetId) {
AssetDto asset = AssetDao.getAssetById(assetId);
List<QuestionDto> questions = AssetDao.getQuestionsByAssetId(assetId);
asset.setQuestions(questions);
return asset;
};
}
2
Is it simply a matter of team discipline or is there some pattern I can use to prevent this?
Yes, it is a matter of some guidelines in naming pattern for the team. You may set simple 4 methods like GetEntityById(), GetAllEntities(), SetEntity(), DeleteEntityById().
In addition, you may have two dto’s with the naming AssetSimpleDto GetAssetById(assetId) and another detailed dto called as AssetDto GetAssetDetailById(assetId) . The first method and dto is customized to bring bare minimum , while second is bringing all related information that your functionality may need.
1