OBGM-578,580,582 Move save and delete to service layer for BudgetCode, GlAccount and PaymentTerm#4144
OBGM-578,580,582 Move save and delete to service layer for BudgetCode, GlAccount and PaymentTerm#4144awalkowiak wants to merge 3 commits intofeature/upgrade-to-grails-3.3.10from
Conversation
awalkowiak
requested review from
alannadolny,
drodzewicz,
jmiranda and
kchelstowski
|
I thought it was a rather small change, hence I decided to move it to service instead of annotating the controller methods. |
jmiranda
left a comment
jmiranda
left a comment
There was a problem hiding this comment.
As I mentioned in previous PRs, I don't want to create a service for every domain class.
https://tedvinke.wordpress.com/2017/04/04/grails-anti-pattern-everything-is-a-service/
So I think we need to come up with a better strategy during a tech huddle. These are all things related to accounting, so maybe AccountingService makes the most sense. Or if we do decide we want to create a separate class for each domain then we should consider implementing the DAO or Repository pattern.
I just found an SO article on Domain Drive Development. I have no idea what it entails but we should add that to the discussion as well.
https://stackoverflow.com/questions/2378069/ddd-with-grails
Anyway, we need to do some more thinking about this before proceeding. In the meantime, I would prefer using @transactional on controller actions that are basically scaffolding. I know that's not ideal, but until we come up with a decent solution we shouldn't be refactoring code.
3 participants
No description provided.