#design-patterns #boundary
#шаблоны проектирования #граница
Вопрос:
Я видел несколько примеров, дающих класс границ, такой как LoginForm и т.д. На первый взгляд это звучит правильно. Но в реальном приложении, где у меня есть CRUD (минимум 4 функции) для каждой модели / объекта, правильнее ли сгруппировать все функции для одного объекта в 1 класс?
например.
<<Boundary>>
TransactionForms
================
insertTransaction(...)
updateTransaction(...)
deleteTransaction(...)
listTransactions()
Ответ №1:
Было бы лучше иметь что-то вроде приведенного ниже для граничных объектов,
FormService
insert(..)
update(..)
list(..)
delete(..).
Внутренне эти методы используют службу транзакций для обновления постоянного уровня.
TransactionService
invoke(...)
Комментарии:
1. Эмм… является
FormService
общим, поскольку он обрабатывает вставку и для других объектов? Или вы имелиTransactionFormService
в виду что-то подобное использованиюTransactionService
? ДляTransactionService
, будет вызывать выглядетьinvoke(method, params)
? Или как это будет работать? На каком уровне он находится?