Ax2012 SysOperation в пакете

[ta_and]

Цитата:

Сообщение от belugin

Контроллер занимается в том числе и упаковкой и распаковкой в контейнеры.

Пакетник занимается распаковкой и запуском задачи.
Почему сразу не упаковать нужные данные в нужные контейнеры чтобы пакетник просто запустил нужную задачу с нужными данными?.
Зачем здесь контроллер?!
Ежики не скрещиваются.
Цель контроллера - обеспечить вызов процесса с нужными данными.
Цель сервиса - получить данные и выполнить действие.
Цель пакетника - получить данные и выполнить действие.
Объясните мне, пожалуйста, где у меня прокол в логике?
-------
Не надо кивать в сторону сложности реализации.
В пакетнике все равно идет анализ что выполняется - ранБэйз или другой класс.
Почему было не заточить пакетник именно на выполнение сервиса? Без контроллера?

[belugin]

Цитата:

Сообщение от ta_and

Пакетник занимается распаковкой и запуском задачи.
Почему сразу не упаковать нужные данные в нужные контейнеры чтобы пакетник просто запустил нужную задачу с нужными данными?.
Зачем здесь контроллер?!

Сейчас этим занимается контроллер - (на нем можно переопределить, например lastValue* функции)

Цитата:

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

Обеспечение нужными данными может быть кастомное. Вы можете изменить алгоритм упаковки и распаковки. Сейчас это прибито гвоздями к контроллеру (ну еще можно сдедать контракт packable).

[ax_mct]

Цитата:

Сообщение от ta_and

Пакетник занимается распаковкой и запуском задачи.
Почему сразу не упаковать нужные данные в нужные контейнеры чтобы пакетник просто запустил нужную задачу с нужными данными?.
Зачем здесь контроллер?!
Ежики не скрещиваются.
Цель контроллера - обеспечить вызов процесса с нужными данными.
Цель сервиса - получить данные и выполнить действие.
Цель пакетника - получить данные и выполнить действие.
Объясните мне, пожалуйста, где у меня прокол в логике?
-------
Не надо кивать в сторону сложности реализации.
В пакетнике все равно идет анализ что выполняется - ранБэйз или другой класс.
Почему было не заточить пакетник именно на выполнение сервиса? Без контроллера?

Как понимаю потому что Контроллер играет здесь еще и роль Фасада к Модели.
При этом Контроллер выполняет часть функций Модели.
Искать логику MVC здесь не стоит, ее просто нет в этой каше.

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

Я вообще предлагаю все классы накрошить на MVC. Взять то же чтение-запись файлов.
А то стыдно прям за неудобренную до конца систему.

[ta_and]

Цитата:

Сообщение от ax_mct

Искать логику MVC здесь не стоит, ее просто нет в этой каше.

Грустно это.
Хотелось как лучше.
А получилось как всегда.
Концепция Контроллера все портит.
Должно было быть сделано все проще и топорней.
Есть контракт - данные - здорово.
Есть контроллер - интерфейсная часть. - вот тут и налажали
Есть сервис - бизнес-логика. - здорово.
---------
Вот если бы не налажали, тогда бы был MVC.
А так - получилось как всегда.
Зачем бизнес-логику обработки и анализа данных было запихивать в контроллер - не понятно.
Дело контроллера маленькое - взять контракт, показать пользователю и отправить сервису.
Зачем усложнять?
Сервис должен сам все знать о данных...
Для особо сложных случаев есть уибилдер и подсовываемые формы.
Но это опять же View.
Т.е. в моем понимании контроллер в АХ должен быть на уровне View.
А его замесили в Controller - Process, без учета специфики Ах классов.
Поэтому у меня ежики и не скрещивались.
Теперь скрестились....