1. Никаких провайдерова в Payment быть не должно. Пользуясь твоей терминологией: мухи и котлеты отдельно
2. Какая-то хрень
3,4,5 и тд решаются не в Model

В итоге никакой логики кроме persistens, мелких вычислений, элементарных проверок в ней быть не должно.
В твоих русскоязычных вики пачкают только такие как ты, а ты это потом эут шняго развозишь по форуму

МСУSeVa1. Никаких провайдерова в Payment быть не должно. Пользуясь твоей терминологией: мухи и котлеты отдельно
Что такое у тебя Payment? Дата класс? Ни в дата классе, ни в DTO никаких провайдеров не должно быть. В PaymentModel (если логики много - можно и через некий new PaymentService(PaymentModel)) - должен быть провайдер, о котором ты писал выше. В данном случае в PaymentModel - бизнес логика, если у нас некий PaymentService - то логика размазывается и на него. Но это для особо замороченных случаев. Тебе рано про них еще знать.

SeVa2. Какая-то хрень
...у тебя в голове.

SeVa3,4,5 и тд решаются не в Model
А ч о чем.

SeVaВ итоге никакой логики кроме persistens, мелких вычислений, элементарных проверок в ней быть не должно.
В твоих русскоязычных вики пачкают только такие как ты, а ты это потом эут шняго развозишь по форуму
Интеграция между системами - это не логика модели. Периодическая проверка в неком сервисе и апдейт поля по какому-то признаку и рассылка - это не логика модели. Наличие признака и проверка его - это логика. У тебя каша в голове.

Это у вас каша и писсуары в головах.
авторЕсли называть дата-модель (классы ORM) - моделью (в терминах MVC), то да. Но использовать дата-модель в качестве модели в MVC - моветон. Выльется боком. Итого, модель не просто передатчик, а именно класс с бизнес-логикой.

В огороде бузина, а в Киеве дядька.

Все "если,то" выше - это и есть бизнес-логика, которую нужно обеспечивать и делается это не в Model

и не в одной строчке очередного маразма из серии DataService
автор PaymentSystem<Payment>>.ActivatePayment(item);


В общем понятно, что ничего подобного ты не делал. Ковыряйся в говнокоде дальше и не вякай.

МСУГде-то в степиМСУ, Почему использование дата модели в трансляции в одностороннем порядке может выльется ?
Я сто раз уже писал - независимость от ORM , бесшовная имплементация любого хранилища.


Детский потуги говнокодера. Муся, предлагаю этому чудо-сервису дать название "Сделайте мне красиво".
Чистый маппинг никому не нужен.

Где-то в степиSeVaпропущено...


В общем понятно, что ничего подобного ты не делал. Ковыряйся в говнокоде дальше и не вякай.
Сева ты как упрямый фома
В одном переулке
Стояли дома.
В одном из домов
Жил упрямый Фома.

Ни дома, ни в школе,
Нигде, никому -
Не верил
Упрямый Фома
Ничему.
Приведи хоть пример своего - говнокода, вот честно сказать смотрю на твои посты где соглашаюсь где нет
Но не разу в жизни не видел ни одной пделки от тебя ни одного примера. ну как так можно голословно
и безапеляционно AAAA?


С моими поделками даже с тебя можно было бы стакан молока поиметь, после недели дрессировки, чтобы выучил несколько незамысловатых правил, тк кода нужно минимум

МСУSeVaДетский потуги говнокодера. Муся, предлагаю этому чудо-сервису дать название "Сделайте мне красиво".
Чистый маппинг никому не нужен.
Иди в зоопарк, предложи писать логику в контроллере. Звери посмеются.

SeVaС моими поделками даже с тебя можно было бы стакан молока поиметь, после недели дрессировки, чтобы выучил несколько незамысловатых правил, тк кода нужно минимум
Да нету у тебя никаких поделок и небыло, все твои посты на форуме - пук в кусты. Да и чмырят тебя все кому не лезь, что не пост - то в мемориз.

Ты еще не дорос, чтобы что-то понимать. Даже принцип единичной ответственности и то не осилил, да ты о нем даже не слышал.
Одним говоришь, что применяй такой-то и такой-то паттерн, другим приходится полчаса объяснять что они из себя представляют, а ты у нас особый случай, тк нужен минимум год, чтобы до тебя что-то дошло. Ты до простого контроллера не дорос, а если начать рассказывать и показывать, что в действительности нужно, то у тебя крышу снесет.

Lord BritishSeVa...

А теперь нарисуй диаграмму для такого Use case:

1.Провести оплату через провайдера.
2. Если оплата прошла успешно, то сопоставить ее с неоплаченными счетами. Если нет, то показать ошибку пользователю
3. Передать данные об оплате в 1С
4. Всем полностью оплаченным Счетам изменить статус на Оплачено.
5. Если есть полностью оплаченные Счета, то :
- произвести уведомление Менеджеров по e-mail
- запустить складской процесс по резервированию на складе
- etc
- etc

Где здесь бизнес-логика и как ты ее будешь реализовывать исключительно в Мodel? Процессов несколько, возможны ветвления кто и как будет проводить их оркестровку?


Попробовал запилить согласно подходу DDD (Eric Evans - Domain Driven Design). В инфраструктурном слое, считаем что для интерфейсов реализации тупо ставят в очередь и возвращают управление сразу (а уже другие системы никак не связанные с этой занимаются рассылкой и т. п.). Иначе долго это все набивать на клаве всякие асинхронные вызовы/воркфлоу и т. п.. В приложении также портянка Sequence диаграм. Пример только чтобы показать какая логика где находится при подходе DDD.


Молодец, весьма неплохо.



SyncPaymentData,_notificationService.Notify,_stockSystem.StartReservationProcess лучше всего выполнять в отложенном режиме и здесь весьма неплохо подходит CQRS и очереди сообщений с гарантированной доставкой. Сейчас поздно, завтра продолжим