Ax2012 SysOperation в пакете

[ta_and]

Здравствуйте.

Все знают, что фреймвок SysOperation был задуман с целью разделить презентационную и бизнес-логику.

Внимание, вопросы:
Зачем при запуске в пакетном режиме создается экземпляр класса Controller?
Почему сразу было не создавать экземпляр класса сервиса и распаковывать ему на вход контракт?

--------------------------------
ПС.
Как я понимаю, смысл пакетного задания - выполнить бизнес-логику.
Смысл сервиса тоже выполнить бизнес-логику.
Задача контроллера - зафигачить запрос пользователю и подготовить правильный контракт на вход сервиса.
Не скрещиваются у меня в голове ежики....

[kashperuk]

Контроллер на клиенте наверное живет? А сервис на сервере?

[ta_and]

Цитата:

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

Контроллер на клиенте наверное живет? А сервис на сервере?

Верно.
Вообще-то пакет выполняется на сервере. Как и нормальный сервис.
Вопрос я поэтому и задаю.
Зачем в пакете создается экземпляр контроллера?

[belugin]

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

[ax_mct]

Цитата:

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

Внимание, вопросы:
Зачем при запуске в пакетном режиме создается экземпляр класса Controller?
Почему сразу было не создавать экземпляр класса сервиса и распаковывать ему на вход контракт?

Потомушто поклоняемся новому богу MVC.
Смысл только один - жертвоприношение.
Чтобы дал нам надежности и простоты кода

Даже чтобы открыть диалоговую форму используем Controller. То есть в точке входа ставим Controller и он всем рулит.

AX 2012 - sysOperation Framework - Use controller class to open dialog from AX form
https://community.dynamics.com/ax/b/...g-from-ax-form

Этот же товарищ обьясняет
Model - parameters [contract class]
View - Dialog [contract class or an optional UI builder class]
Controller - Process (the code that runs in the essence of pattern)
То есть смысл один - бессмысленно следовать паттерну.

AX 2012 - sysOperation Framework implementation [Example]
http://daxture.blogspot.ru/2016/03/a...framework.html

[mazzy]

Цитата:

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

Смысл только один - жертвоприношение.

Богу юнит-тестирования )

Цитата:

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

Чтобы дал нам надежности и простоты кода

и легкости в создании моков.

Цитата:

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

Этот же товарищ обьясняет
Model - parameters [contract class]
View - Dialog [contract class or an optional UI builder class]
Controller - Process (the code that runs in the essence of pattern)

...и адаптеры!

Цитата:

С трибуны неслось:
— ...и в такие дни, как наши, когда каждый из нас должен отдать все свои силы на развитие конкретных лингвистических исследований, на развитие и углубление наших связей со смежными областями науки, в такие дни особенно важно для нас укреплять и повышать трудовую дисциплину всех и каждого, морально-нравственный уровень каждого и всех, духовную чистоту, личную честность...
— И животноводство! — вскричал вдруг требовательно Петенька Скоробогатов, вскинув вперед и вверх вытянутую руку с указательным пальцем

http://arzamas.academy/materials/741

[ax_mct]

Цитата:

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

http://arzamas.academy/materials/741

Возможно именно мне давно пора в животноводство,
но господа программирующие для AX7 (вне системной команды Microsoft) - они по ходу сталкеры

Цитата:

-- отчаянные парни, которые на свой страх и риск проникают в....
-- Понимаю. Нет, это вне нашей компетенции.

[belugin]

Вопрос знатокам, рассуждающим о паттернах: Какое имеено правило MVC нарушается в SysOperation Про "паттерн" хорошо написано на Хабре

[ax_mct]

Цитата:

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

Здравствуйте.

Все знают, что фреймвок SysOperation был задуман с целью разделить презентационную и бизнес-логику.

Внимание, вопросы:
Зачем при запуске в пакетном режиме создается экземпляр класса Controller?
Почему сразу было не создавать экземпляр класса сервиса и распаковывать ему на вход контракт?

--------------------------------
ПС.
Как я понимаю, смысл пакетного задания - выполнить бизнес-логику.
Смысл сервиса тоже выполнить бизнес-логику.
Задача контроллера - зафигачить запрос пользователю и подготовить правильный контракт на вход сервиса.
Не скрещиваются у меня в голове ежики....

Цитата:

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

Вопрос знатокам, рассуждающим о паттернах: Какое имеено правило MVC нарушается в SysOperation Про "паттерн" хорошо написано на Хабре

belugin, еще раз спасибо за фундаментальную статью достойную диссертации.

ta_and, чутье не подводит, мне тоже видится что реализация MVC в SysOperation бестолковая.
И Controller действительно не поймешь что.
Тонкая Model и толстый Controller - это уродливо.

Для меня MVC в SysOperation это не более чем бифуркация кода штабными умниками. Да, пишут что это теперь удобнее для вызова через AIF и прочее. Кому удобнее я правда так и не понял.

Цитата:

The sysOperation framework is an implementation of the MVC pattern (Model-View-Controller)

Model - parameters [contract class]

View - Dialog [contract class]

Controller - Process (the code that runs in the essence of pattern)
The framework influence the Services framework, whereas a service in AX has a data contract with some special attributes

DataMember attributes in contract class take the entered values in parameters (dialog fields) to the process (aka "operations")

Если исходить из нормального MVC, то что
Model - parameters и
Controller - Process
- это дичь полная.

[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, без учета специфики Ах классов.
Поэтому у меня ежики и не скрещивались.
Теперь скрестились....