Для кого Best Practice?

[MikeR]

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

[sukhanchik]

Цитата:

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

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

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

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