Для кого Best Practice?

[MikeR]

Я решил вернуться в DAX, коллеги. Как что и почему в личку.
Открываю d365fo форму salesTable и нахожу более десятка

ttsbegin

в методах контролов формы. То есть Best Practice это для работяг, а настоящим пацанам можно?

[Владимир Максимов]

Ага, нашел наконец статью Best Practices с этой рекомендацией. Фиг найдешь еще ее на сайте Microsoft. Там вообще трудно что-то найти, если точно не знаешь где искать...

https://docs.microsoft.com/en-us/dyn...-code-in-forms

Вообще-то, все рекомендации Best Practices направлены на облегчение сопровождения кода. На то, что будет "потом". "Когда-нибудь". А при собственно написании кода - это некие дополнительные действия, которые именно в момент написания кажутся не очень-то и нужными. Ну и получаем, то, что получаем

[wojzeh]

в статье вроде не о транзакциях, а том, что вообще на форме кода должно быть минимум.
но как учили классики

Цитата:

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

[MikeR]

Цитата:

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

...вообще на форме кода должно быть минимум.
но как учили классики

И это актуально для D365FO, не говоря про код, да еще на контролах, где вообще кода быть не должно в принципе, а не просто кода, а самые что ни на есть транзакции. Получается, что обучающие ролики по D365FO про формы- ложь.
Те, решения которые вендор браковал по причине плохо написанного кода - это лишь надуманные придирки. Да и форма не из какого-нить купленного модуля. Форма то статусная - SalesTable. Думаю продолжать не имеет смысла, что не так...
Пишите дальше в таком же стиле, вы разработчик, не простой какой-нибудь, а разработчик Майкрософт. Это статусно.

[wojzeh]

Сорян, я вообще не понял, что ты сказать хотел.
И нет, я не разработчик майкрософт.

В целом я согласен, что best practice написаны если не кровью, то слезами и соплями, но иногда жизнь диктует нам суровые законы, как говорил Остап Ибрагимович

[AlexSD]

А что с ttsbegin в методах контролов D365 не так?

[wojzeh]

Цитата:

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

А что с ttsbegin в методах контролов D365 не так?

например (подставьте любую песню, которую пользователь поёт внутри открытой транзакции)

ttsBegin;
I'm waiting for the night to fall
I know that it will save us all
When everything's dark
Keeps us from the stark reality
I'm waiting for the night to fall
When everything is bearable
And there in the still
All that you feel is tranquillity
There is a star in the sky
Guiding my way with its light
And in the glow of the moon
Know my deliverance will come soon
I'm waiting for the night to fall
I know that it will save us all
When everything's dark
Keeps us from the stark reality
I'm waiting for the night to fall
When everything is bearable
And there in the still
All that you feel is tranquillity
There is a sound in the calm
Someone is coming to harm
I press my hands to my ears
It's easier here just to forget fear
And when I squinted
The world seemed rose-tinted
And angels appeared to descend
To my surprise
With half-closed eyes
Things looked even better
Than when they were open
Been waiting for the night to fall
I knew that it would save us all
Now everything's dark
Keeps us from the stark reality
Been waiting for the night to fall
Now everything is bearable
And here in the still
All that you feel is tranquility
ttsCommit;

[AlexSD]

Цитата:

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

например (подставьте любую песню, которую пользователь поёт внутри открытой транзакции)

Ну, вы проверьте сами. В форме SalesTable нет кода, который состоял бы только из ttsbegin. Везде указана пара вызовов ttsbegin/ttscommit. Т.е. у пользователя нет времени на музицирование между ttsbegin и ttscommit.

[Logger]

Цитата:

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

А что с ttsbegin в методах контролов D365 не так?

Дык...
Не по феншую.

И эти люди запрещают нам ковырять в носу, тьфу, делать оверлейинг.

[ta_and]

Это еще ладно... а вот за какое место нужно гладить программиста M$ за то, что он делает ПРИВАТНЫЕ методы в классе - обработчике?
Надеюсь, всем понятно, что изменить мы этот метод в d365 напрямую мы не можем. Мы можем только сделать чайн класс. и попытаться перекрыть этот метод там... да вот незадача, приватные методы не перекрываются чайн-классом. А внутри этого метода без всяких дополнительных методов делается куча работы строк на 100500 без всяких шлюзов и вызовов других методов, с помощью которых можно было бы повлиять на выполнение этого не побоюсь этого слова г...
И вот приходится полностью дублировать класс, и подменять его вызов. И хорошо, что это вызов из пользовательского меню. А если бы этот вызов был бы зашит где-нибудь программно из других классов... А что если бы были наследники?... в общем шедевр на шедевре.
я уж не говорю о том, что методы стандартных классов должны, в принципе быть помечены как Replaceable - для того, чтобы разработчик мог НЕ вызывать стандартный next, если он не нужен..

[trud]

Цитата:

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

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

Чем тогда это будет отличаться от оверлеинга(да еще и с кучей ограничений)? Т.е. изначальная идея-то в том чтобы не меняли стандартное приложение

Цитата:

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

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

Ну т.е. понятно что хакнуть можно все что угодно. Но перед этим делательно получить подтверждение от пользователя(и лучше письменно), что они осознают, что выполняя данную модификацию они получат не поддерживаемую систему

[AlexSD]

А, феншуй... Ну, тогда да.

Я думал про то, что раньше был практический смысл, делать меньше кода, который выполняется на стороне клиенте. Сейчас в D365 весь код работает на "АОС". Так что, с этой точки зрения здесь остался только феншуй.

Вендор (МС) - это тысячи сотрудников, и каждый первый со своими тараканами в голове. Не всем (и не всему) нужно верить

Я ушел из МС 6 лет назад. Сейчас у меня появились задачи, которые я делаю для МСа в качестве внешнего вендора-контрактника. Мой код ревьювят так же, как я когда-то ревьювил чей-то код (Серега В., привет ). Появились новые БП, некоторые БП поменялись/отменились за это время. Все меняется. Не со всеми комментариями моего кода я соглашаюсь. Спорю и доказываю, что так, как сделал я, лучше и оптимальнее. БП придумывали люди для определенных ситуаций. Эта ситуация поменялась, БП - тоже меняется.

ЗЫ. Depeche Mode forever

[wojzeh]

Цитата:

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

Depeche Mode forever

amen!

[MikeR]

Я помню, что меня за заполнение двух полей на методе write datasource распинали бронзовые товарищи в свое время. А тут целая транзакция в контроле форме. Ребята, да вы, вообще, с паттерном MVC знакомы?
В PHP если вы делаете вставку записи на уровне контролера, не говоря уже про view, то ваш код не пройдет проверку в нормальной конторе, это уровень модели, а то и ниже.
Форма в АОТ - это некий симбиоз view + controller. Какие транзакции?! Причем здесь выполнение на клиенте?!
Мы теперь в форме весь код держим, так что ли? Нужно записать, обновить. удалить, не стесняемся...

[sukhanchik]

Цитата:

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

Мы теперь в форме весь код держим, так что ли? Нужно записать, обновить. удалить, не стесняемся...

Мировоззрение поменялось. Форма теперь - это по сути особый класс, который с т.з. того же PHP работает на сервере и тут нет клиентской части.
Так что в общем-то особо нет разницы (с т.з. производительности) где расположен код. Другое дело, если эту транзакцию надо вызвать не только с этой формы. Но это уже не вопрос производительности. А архитектура может меняться настолько непредсказуемо, что один фиг может потребоваться полная переделка. Поэтому логично сделать не заморачиваясь.

[wojzeh]

Цитата:

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

Мировоззрение поменялось. Форма теперь

мировоззрение, может, и поменялось, а форма-то сама поменялась в этом плане?
по-моему, большинство объектов тихо переехали по программе реновации и похорошели

[MikeR]

Цитата:

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

Мировоззрение поменялось. Форма теперь - это по сути особый класс, который с т.з. того же PHP работает на сервере и тут нет клиентской части.

Просто проектанты из мс не знают паттернов. На собеседовании спрашивают, какие фуркты и как переместить из одной карзины и куда.

Цитата:

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

А архитектура может меняться настолько непредсказуемо, что один фиг может потребоваться полная переделка. Поэтому логично сделать не заморачиваясь.

Если архитектура строится не на паттернах, грош ей цена. Поэтому и переделывается несколько раз, так как нет понимание как делать.

[AlexSD]

Цитата:

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

Я помню, что меня за заполнение двух полей на методе write datasource распинали бронзовые товарищи в свое время. А тут целая транзакция в контроле форме. Ребята, да вы, вообще, с паттерном MVC знакомы?

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

[MikeR]

Слава богу народ в open source (php) переболел безумием отказа от паттернов. А с аксаптой все граздо хуже. И это подтверждает тот факт, что на собеседовании допустим в авито, вас будут спрашивать про паттерны, а вот если проходить собеседование по аксапте, то про паттерны либо не будут спрашивать, либо будут спрашивать уже на должность арихтектора. Условный разработчик по аксе условно плохо представляет SOLID.
В строительстве без паттернов можно строить быстро и дешево хозблоки, но никак не возможно построить высотное здание типа Москва Сити с сложной архитектурой и коммуникациями.
Программирование - очень молодая отрасль и те, кто привык не отходя от формы делать в ней все, еще достаточно много, Но надо понимать, что аксапта должна сильно отличаться от движка блогов.
Опять же если в строительстве высотного здания использовать деревянный фундамент, то оно просто рухнет. Так как за эти столетия накопился опыт и стратегии, появились ГОСТ-ы.
В программировании аксапты пока есть понимание, что на клиенте, выполнять код плохо, Это самое, самое начало...
Так вот php код тоже всегда выполняется на web сервере, это не клиентские сценарии js. И тем не менее уже есть понимание, что делать в view, контроллере и модели.
Да я вижу, что sales Table не подходит под паттерн проектирования. Его просто нет. Так зачем тогда мурыжить в тренингах по разработке, что не пишем код на формах. Очередная промывка мозгов?

[sukhanchik]

Цитата:

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

Так зачем тогда мурыжить в тренингах по разработке, что не пишем код на формах. Очередная промывка мозгов?

Тренинги писались для более ранних версий, чем D365, а там это правило было актуально.
Вообще, на все это можно посмотреть с другой стороны. Когда-то раньше наверняка существовало правило, по которому в SELECT-ах нужно было указывать индекс (INDEX HINT), по которому нужно осуществлять выборку. Потому что не было СУБД, а была просто БД (типа DBF-ок) и программист сам должен был указывать индекс, по которому осуществлять выборку.
Тоже самое можно сказать про транзакции и технологии, их заменяющие (таблицы *Delta, поле createdTransactionId и т.д.)
Сейчас уже никто не задумывается над тем, какой индекс возьмет БД (лишь бы он был). Также все знают, что ttsbegin / ttscommit заведомо решат все задачи транзакций.

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