Цитата:
Сообщение от
Владимир Максимов
Т.е. сама постановка задачи, мягко говоря, идет в разрез с логикой работы с Axapta. Методы на таблицах типа salesLine.SalesTable() создаются либо от непонимания (привычка из другой среды программирования), либо из-за особенностей конкретного обращения к конкретной таблицы (сложность алгоритма, дополнительное поле и т.п.)
Иными словами, такой способ организации поиска записи таблицы-родителя в среде Axapta сам по себе является исключением. Нетипичным обращением. Ну, и зачем пытаться вывести некое универсальное решения для исключений?
PS: На всякий случай уточню. Это правило для младших версий Axapta (с которыми автор и работает). Для старших - в настоящее время еще нет устоявшихся правил. Все меняется на лету. Даже в рамках одной версии
Вы абсолютно не правы. Судя по вашему мнению, разработчики MS совершенно не понимают, что пишут... Подобные методы есть и в последних версиях Аксапты, будь то 2012 или D365. Вы можете игнорировать подобный подход и топорно вызывать find() по старинке. Однако оптимальный код должен быть простым и компактным. Т.е. нормальный разработчик старается вызывать методы либо вообще без параметров, либо с минимальным их набором.
Плюс вашего подхода - используем чисто find() и не паримся с доп. методами типа salesLine(). Минус же в том, что вам нужно помнить внешний ключ (SalesId-то все знают, а если рассматривать более редкую таблицу, а если ключ составной?). Плюс моего подхода - такая же унификация по имени метода как и find, но также метод может вернуть любую таблицу, которая там прописана. А find - не может. Другой плюс - нам не нужен ключ к таблице, нам нужна сама таблица.