Repositories / Gateways and Write Access Interface

[Boas Enkler]

Hi,

 

in the meanwhile I use Repositories / Gateways very similar to the ideas which were proposed in the CleanCode Component Videos.

Also sometime ago I asked here https://groups.google.com/forum/#!starred/clean-code-discussion/TvuJP8ISazA wether to use specific or generic read functions.

using specific function has turned out be have a great benefit on readable code, simpler unit tests  and development performance.

But there is an implementation detail I don't feel sure. 

Its about writing data with the repository

 

The summary is that I'm not sure whether I would always have generic save / update Methods (so for example one base implementation for all gateways of one technology) or more specific versions.

 

Given the following scenario: A user has a appontment management application. In this we have appointments with title, description and reminder date...

Now the user changed the reminderdate (remind me in 5 minutes)

In detail here are the two approaches I’m thinking about how the Gateway (which is called form the SetNewReminderInteractor) can look like:

 

A

A.1 Having an as specific as possible Method on the Gateway which is called by the interactor. For Example 

IAppointmentRepository.SetRemindDate(id,remindDate)

 

A.2 Giving this method a specific Model

 IAppointmentRepository.SetRemindDate(ReminderUpdateModel)

 

or

B

 

B) Having a generic update method like

IAppointmentRepository.Update(AppointmentEntity). 

 

 

Thoughts about A

 

A.1 :

This way I can unit test very easy. Ensuring that a call to SetReminderDate is enough to make sure that the interactor would trigger the update. But it is not entity based. Is that ugly?

I also think about A.2 which puts all information in a specific ReminderUpdateModel. Thus making it more save for further changes (but currently non are known or required so YAGNI?)

 

Thoughts about B

This is more entity oriented but quite more complex. There can be more fields included than required to just set the new remind date.

Also the interactor code is more obfuscated because there is only a generic Update call on the Repository.

 

Extension to B

Also I think about how to handle possibly other changed values. So to be sure that not more is done than expected, in the interactor i should first read an entity, set the new remind date and then save the whole entity by calling Update. To avoid collisions with other changes a user does. And even then a user could change the title in this short time. So I would also need a changed Field Tracker to write only changed fields .

For Example if the user has a “Remind me in 5 minutes” feature. There would be an interactor to renew the reminder. In this szenario only the reminddate should be updated and no collisions with other fields for example title should occur.

 

 

This looks like a bunch complex handling that should be added to implement B.

 

 

So what would you recommend? What are you experiences.