самый простой наверное способ убедиться в том что твое понимание верное - попробовать объяснить другому

Транзакшн я понял как самый бесполезный подход, который просто инкапсулирет каждую операцию в отдельную функцию, и вызывает её при запросе от клиента. ТэйблМодуль основывается на том что каждой таблице сопоставляется объект, который может всячески взаимодействовать с ней. Ну и домэйнмодел это уже полноценное ООП где в основе всего стоят именно сущности, их обязанности и взаимодействие. Как я понял все три подхода теоретически можно сочитать даже плюс добавить поверх них что то вроде контроллера(забыл как называется он).сорян за косноязысность пишу в метро)

Объекты сущностей

>транзакшн бесполезный

А если бы в гитлабе транзакции использовали, 300гб прод базы не улетели бы.

Но если производительность > безопасность, то верно мнение выше.

Я не про транзакции уровня бд

А про паттерн transactionScript

"бесполезный подход" значит я понял не верно, думал достаточно обще.

А если бы в гитлабе транзакции использовали, 300гб прод базы не улетели бы.

Есть такой термин - бизнес транзакция. Это по сути какая-то атомарная операция в контексте бизнес логики. Например - денежный перевод. Транзакционные скрипты же это нечто описывающее последовательность действий и оперирующее данными.

Транзакшн я понял как самый бесполезный подход, который просто инкапсулирет каждую операцию в отдельную функцию, и вызывает её при запросе от клиента. ТэйблМодуль основывается на том что каждой таблице сопоставляется объект, который может всячески взаимодействовать с ней. Ну и домэйнмодел это уже полноценное ООП где в основе всего стоят именно сущности, их обязанности и взаимодействие. Как я понял все три подхода теоретически можно сочитать даже плюс добавить поверх них что то вроде контроллера(забыл как называется он).сорян за косноязысность пишу в метро)

не сказал бы что транзакнен скрипты бесполезны. Это лучше чем ничего, скажем так. Большинство собственно используют именно этот подход и не парятся особо. Вот что такое "тэйблмодуль" я все еще не понимаю. Ты про table gateway? Ну это очень схоже с DAO.

ну то есть например полноценную объектную модель предметной области нужно все-таки где-то хранить (репозиторий), и это что-то должно как-то общаться с базой (DAO)

https://www.google.ru/url?sa=t&source=web&rct=j&url=http://design-pattern.ru/patterns/table-module.html&ved=0ahUKEwia7Yef2PTRAhWhdpoKHef_DZcQFggdMAA&usg=AFQjCNF8eujfFs55sVQnHxvW7p0K9YqvBQ&sig2=sS6tg1vvW1hqigV-Oyw3Rw

Вот это пытался объяснит

хз

Так а можно бизнес транзакций например реализовать поверх domain model?

никогда не понимал людей которые пытаются выучить паттерны

Так а можно бизнес транзакций например реализовать поверх domain model?

хз

domain model как паттерн весьма и весьма мутная концепция

у Эванса есть очень четкая концепция

есть domain model и это совокупность всеъ объектов описывающих предметную область

Та я не пытаюсь выучить, просто читаю книгу и охотно обсудить прочитанное

Та я не пытаюсь выучить, просто читаю книгу и охотно обсудить прочитанное

Дядя Боб (Роберт Мартин) - Чистый Код.

начни с этого

Фаулер шаблоны корпоративных приложений

Дядя Боб (Роберт Мартин) - Чистый Код.

Я читал то ли чистый то ли совершенный код давно еще

совершенный код говно, чистый - норм

это как кокс но код

там несколько веселее чем у Макконела

я даже бумажную версию заказал

а вы следуете правилу одного ассерта, когда пишете тесты?

что за правило такое?)

есть другое правило

тест должен фэйлится только по одной причине

а используешь ты один ассерт или несколько - это уже твое дело

вот оно да

дядя Боб называет это правилом единого ассерта

ассерт (или нексколько) в рамках одного теста должны проверять только одно утверждение

ну, норм. Это позволяет делать более сфокусированные тесты

вот пишешь ты некий клиент для некоего АПИ

клиент должен составить правильный запрос к апи и вернуть обработанный (декодированный) ответ

значит должно быть как минимум два теста, да?

тест на то, что запрос правильный

и на то, что ответ правильно воспринимается

клиент должен составить правильный запрос к апи и вернуть обработанный (декодированный) ответ

в сферическом вакууме составлением запроса будет заниматься одна хреновина а обработкой результата - другая

ты ж не забывай что дядя Боб за юнит тесты впрягает

в сферическом вакууме составлением запроса будет заниматься одна хреновина а обработкой результата - другая

внутри - пожалуйста

идея в чем

ну хорошо, не апи клиент, а некий прокси к удаленному сервису

у тебя есть объект, который обязуется правильно конструировать запросы

и он оттестирован отдельно

и ты его просто юзаешь

и тебя не парят тест кейсы по составлению запросов больше

точно так же будет объект который обрабатывает какой-то результат

понял тебя

здраво, да

и он тоже оттестирован отдельно

НО

есть третий объект который юзает эти два

и его нельзя покрыть юнит тестами

просто потому что все что он делает - просит сначала один объект что-то сделать и потом второй

декларирует флоу

и ты.... такие вещи не проверишь нормально. Это уже интеграционные тесты

ERROR: S client not available

профит тут в том что у тебя может быть один медленный интеграционный тест который проверяет взаимодействие компонентов на сценарии который покрывает весь флоу

и много маленьких и быстрых юнит тестов которые покрывают различные сценарии связанные с формированием запросов/обработкой результатов

иначе тебе придется все эти тест кейсы делать медленными

правда если система небольшая и тесты всеравно выполняются за разумное время (скажем минуту)

то как бы... и так сойдет и не надо дробить слишком сильно

у меня нет ничего медленного

я думаю, что пока обойдусь несколькими отдельными тестами на весь апи клиент

если тебе так удобно и в целом ты все еще можешь запускать тесты часто - норм

у меня вся сюита занимает < 3 сек на сраном тормозном макбуке, так что ок)

Time: 2.85 seconds, Memory: 53.75MB OK (1105 tests, 1468 assertions)

15 месяцев назад было 0 тестов ))

я молодец

Неплохо.

Я на двух крупных проектах спасался исключительно тестами - иначе хоть вешайся (nodejs, python).

15 месяцев назад было 0 тестов ))

у меня на текущем проекте такая ситуация была месяц назад)

правда сейчас где-то сотенка тест кейсов пока-что

на след неделе планирую еще сотенку

сколько у тебя инженеров?

у меня получается около 0.3 теста на инженера в день :)

маловато)

при адских объемах кода, который льется в репу

у меня получается около 0.3 теста на инженера в день :)

у меня на проекте тесты пока только я пишу

как-то людей набежало

толку

Это hr'ы

кого они хотят тут найти

в чате по ООП

?

кого они хотят тут найти

принца на солид`ном коде

солидная девчина ищет солидного мужчину