CODEWITHSUNDEEP
model-view-controller
Ralph
Ralph

Reputation: 897

Data Mapper: One For Each Model or One Size Fits All?

I have noticed that many people recommend creating a data mapper for each model but that can be time consuming. Why wouldn't it beneficial to create a generic data mapper that detects an object's(model) properties(variables) and matches them to a database field?

Upvotes: 0

Views: 30

Answers (1)

Pete Scott
Pete Scott

Reputation: 1526

"Why wouldn't it beneficial to create a generic data mapper"

There are absolutely benefits (e.g. less duplicate code), but there are some potential downsides if you're going to directly consume it. A couple of potential pitfalls (off the top of my head)...

Given this example: IUser user = DataMapper.Map(HashTable userRecord);

  • What happens if the userRecord contains invalid data? Should the Map method verify the HashTable contains all the pertinent information before attempting to fill the User object? Will that verification process vary by object type?
  • What if the object is modified to take a constructor parameter?

I've been down this road myself, and eventually wound up with a lot of objects being built using a generic mapper and other objects using non-generic mappers, and it ends up being very confusing for the developer (which mapper should I use for this object?), and a few bits and pieces of scary "cleverness" inside the mapping methods.

You can absolutely use a generic data mapper, but you may want to consider using it as an abstract base class and writing specialized mappers on top of it to avoid challenges with "special" objects, and to avoid a bunch of deep, potentially dangerous refactoring when an object needs to change in some fashion that the mapper won't support.

[Note that I do not consider myself (even remotely) an expert in the context of data/object mapping, so take anything I suggest with a grain of salt]

Upvotes: 1

Related Questions