В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте

[Dolter]

Цитата:

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

А тупой таймер, который был еще в версии ax2.5, реализовать этой иммитацией можно? Или хотя бы автообновление формы по таймеру?

ОбработкаОжидания() ???

Для любой формы:
ПодключитьОбработчикОжидания(<ИмяПроцедуры>, <Интервал>, <Однократно>)

Плюс:

[mazzy]

Цитата:

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

Для любой формы:
ПодключитьОбработчикОжидания(<ИмяПроцедуры>, <Интервал>, <Однократно>)

Плюс:

Впечатлен!!!!
Спасибо!

Значит таймер на форму повесить можно.
А таймер в других местах - не получится.

Таймер в 1С видимо с точностью до секунд.
Можно ли в 1С реализовать какую-нибудь плавную анимацию, типа тетриса?

[Сисой]

Сомневаюсь, что в 1С8 можно нарисовать плавный Тетрис. Там нет объектов типа shape. Придется перерисовывать на форме элементы управления.
Промежуточный итог: Аксапта лучше приспособлена для написания компьютерных игр :-)

[Dolter]

Цитата:

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

Можно ли в 1С реализовать какую-нибудь плавную анимацию, типа тетриса?

В семерке был метод GetPerformanceCounter()... Наверняка и в восьмерке можно отыскать такой :-)
А плавность шейпов... хто его знает, может через HTML поле сделать :-)

Зачем все это в прикладных задачах-то?

[mazzy]

Цитата:

Сообщение от Сисой

Аксапта лучше приспособлена для написания компьютерных игр :-)

Ок

Цитата:

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

Зачем все это в прикладных задачах-то?

Отображение состояний процессов на одном экране. Всякие энергетики, коммунальщики, железнодорожники...

ок.

Еще есть технологические возможности, по которым 1С приблизилась к Аксапте?

[FE]

Думаю, что это в ветку по платформе. Знающие 1С, расскажите, пожалуйста, как реализовано обновление? Имею ввиду вот что: предприятие ведёт разработку в типовой конфигурации, приспосабливая её под свои нужды. Как в этом случае накатываются обновления, выпускаемые собственно 1С?

Верно ли, что при самостоятельном изменении объектов они "снимаются с поддержки"? Если нет, то при каких условиях можно накатывать стандартные обновления, а при каких нельзя?

Существует ли механизм сравнения, что именно было изменено программистом предприятия по сравнению с типовой конфигурацией?

[Dolter]

Цитата:

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

Знающие 1С, расскажите, пожалуйста, как реализовано обновление? Имею ввиду вот что: предприятие ведёт разработку в типовой конфигурации, приспосабливая её под свои нужды. Как в этом случае накатываются обновления, выпускаемые собственно 1С?

Верно ли, что при самостоятельном изменении объектов они "снимаются с поддержки"? Если нет, то при каких условиях можно накатывать стандартные обновления, а при каких нельзя?

Существует ли механизм сравнения, что именно было изменено программистом предприятия по сравнению с типовой конфигурацией?

даааа.... это пока только мечта для 1С
никаких слоев разработки, ничего и близко нет для облегчения... разве что ремарки в коде :-)(

[Сисой]

Цитата:

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

Думаю, что это в ветку по платформе. Знающие 1С, расскажите, пожалуйста, как реализовано обновление? Имею ввиду вот что: предприятие ведёт разработку в типовой конфигурации, приспосабливая её под свои нужды. Как в этом случае накатываются обновления, выпускаемые собственно 1С?

Верно ли, что при самостоятельном изменении объектов они "снимаются с поддержки"? Если нет, то при каких условиях можно накатывать стандартные обновления, а при каких нельзя?

Существует ли механизм сравнения, что именно было изменено программистом предприятия по сравнению с типовой конфигурацией?

Можно модифицировать объекты с сохранением поддержки.
Да, в конфигураторе 1С реализован механизм сравнения.
Можно выборочно применять/не применять изменения в новой версии.
Самое сложное - код модулей. Есть режим поиска расхождений в текстах, но трудоемкость процесса достаточно ощутимая.
Также непросто анализировать изменения в формах.
Но при переходе к декларативному описанию форм в 8.2 проблема становится менее острой.

[mazzy]

Цитата:

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

я в соседней ветке написал, что ком-коннектор в 1С лучше

А в чем именно? Русские буквы в названиях методов ипеременных поддерживаются?

Цитата:

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

даааа.... это пока только мечта для 1С
никаких слоев разработки, ничего и близко нет для облегчения... разве что ремарки в коде :-)(

Вроде какую-то систему контроля версий обещали?
Или я путаю?

Цитата:

Сообщение от Сисой

Самое сложное - код модулей. ...
Также непросто анализировать изменения в формах.
Но при переходе к декларативному описанию форм в 8.2 проблема становится менее острой.

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

Инструменты сравнения в 1С доделают (надеюсь)
А вот с формами и отчетами (особенно с отчетами) уже ничего не сделаешь - они в 1С гораздо сложнее устроены, чем в Аксапте. Тем более, что пару версий 1Совсцы будут по привычке отключать авторазмещение элементов на форме... А с отключенным авторазмещением простое добавление реквизита может привести к несовпадению всей формы.

Upd: справедливости ради, нужно отметить, что в Аксапте отчеты перенесли в Reporting Service. Там никаких слоев. Там только cvs, который идет с самой VS. Но к нему надо привыкать. И чем кончится переход на Reporting Service с точки зрения легкости апгрейда - пока непонятно

[Dolter]

Цитата:

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

Еще есть технологические возможности, по которым 1С приблизилась к Аксапте?

я в соседней ветке написал, что ком-коннектор в 1С лучше

[SolNik]

Цитата:

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

я в соседней ветке написал, что ком-коннектор в 1С лучше

"На этой карете прошлого далеко не уедешь" . В следующих версиях AX от него вообще планируют отказаться (так по крайней мере пишут в мануале разработчика для DAX2009). Взамен него используется более перспективный в плане скорости и удобства работы .NET Business Connector.
А вот тут как я понимаю у 1С как раз все не очень здорово. Точно знаю, что платформа 8.1 не может выступать сама как .NET провайдер. И похоже, что внутри нее подключить .NET компоненты (CLR сборки) и использовать их как "родные" элементы конфигурации, нет возможности.

+ что, еще разочаровало в платформе 8.1:

1. Отсутствие возможности параллельной разработки нескольких программистов в одной конфигурации и одной базе. Как мне кажется, на больших проектах это сильно усложняет регламент разработки.
+ сюда же - необходимость перезапуска клиента 1С для того, чтобы протестировать изменения в конфигурации (что тоже скорости разработки не добавляет).

2. Отсутствие полноценного наследования и остальных атрибутов настоящего ООП. При проектировании новой сложной функциональности (как сам MS, так и партнеры) могут использовать все современные методики проектирования ПО опираясь на общепринятую терминологию (ООП паттерны (GOF, Фаулер), рефакторинг, UML и т.п.).
Какие методики при проектировании архитектуры масштабных решений (на их самобытном фреймворке) использует 1С мне не очень понятно.

3. Как я понял в типовых конфигурациях повсеместно используется подход - реализация бизнес-логики на модулях форм. Как мне кажется, связано это с пунктом 2.
От этого, "детские болезни", о которых писал mazzy (бешеный траффик между клиентом и АОС-ом и т.п.) становятся совсем недетскими . Так как, как мне кажется, связаны опять таки с подходом к проектированию бизнес-логики в 1С.
Поэтому, чтобы вылечить эти "детские болезни", скорей всего потребуется тотальное переписывание типовых конфигураций.
А это означает, что клиентам 1С придется еще не раз внедрить систему с чистого листа, чтобы перейти на более прогрессивные версии.

4. Не реляционная структура БД.
Спорный, кончено, момент. Но, ИМХО, на данный момент существующие технологии объектно-реляционного преобразования не позволяют достичь такой же производительности, как если бы структура была чисто реляционной.
+ мы теряем возможность полноценного использования некоторых встроенных в СУБД средств оптимизации (partitioning напрмер) и аудита (трейсинг тяжелых запросов например) производительности.


Да и еще хотел еще раз подчеркнуть не раз звучавший здесь тезис - MS, в отличии от 1С вкладывает немалые усилия в сохранение преемственности версий, или как они выражаются "в сохранение инвестиций", сделанных партнерами и клиентами.
Выражено это во многом: начиная от формирования таких вот документов (Arijit Basu: Statement of Direction for Microsoft Dynamics AX), и заканчивая разработкой целых фреймворков для облегчения переноса данных между версиями не только для стандартного функционала, но и доработок (http://www.microsoft.com/downloads/d...displaylang=ru).
Сам был свидетелем двух параллельно идущих проектов в одной компании - один по переходу с Axapta 3.0 на DAX4.0. Другой - с 1С Бух 7.7 на 1С Бух 8.0. Проект по Аксапте занял 3 месяца с учетом работ по оптимизации и аудиту. Причем сам подъем приложения занял не больше двух человеконедель, остальное время - тестирование, оптимизация, перенос данных.
1С же по сути внедряли с нуля в течении года (хотя там были проблемы с менеджментом проекта, но тем не менее).

[Сисой]

Цитата:

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

"+ что, еще разочаровало в платформе 8.1:
1. Отсутствие возможности параллельной разработки нескольких программистов в одной конфигурации и одной базе. Как мне кажется, на больших проектах это сильно усложняет регламент разработки.

Это еще что за миф? Хранилище для коллективной разработки есть с версии 8.0.
Хоть 50 программистов подключай.

Цитата:

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

...Поэтому, чтобы вылечить эти "детские болезни", скорей всего потребуется тотальное переписывание типовых конфигураций.
А это означает, что клиентам 1С придется еще не раз внедрить систему с чистого листа, чтобы перейти на более прогрессивные версии.

Соглашусь. Скорее всего именно так и будет. Кормушка открыта, господа.

[miklenew]

Цитата:

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

А вот тут как я понимаю у 1С как раз все не очень здорово. Точно знаю, что платформа 8.1 не может выступать сама как .NET провайдер. И похоже, что внутри нее подключить .NET компоненты (CLR сборки) и использовать их как "родные" элементы конфигурации, нет возможности.

.net это технология MS врятли 1С будет в эту сторону смотреть.
1С вполне самодостаточный продукт. я думаю у них хватит сил чтоб не использовать чужие наработки. А создать что-то своё, более удобное и компактное.

[Dolter]

Цитата:

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

"На этой карете прошлого далеко не уедешь" . В следующих версиях AX от него вообще планируют отказаться (так по крайней мере пишут в мануале разработчика для DAX2009). Взамен него используется более перспективный в плане скорости и удобства работы .NET Business Connector.
А вот тут как я понимаю у 1С как раз все не очень здорово. Точно знаю, что платформа 8.1 не может выступать сама как .NET провайдер. И похоже, что внутри нее подключить .NET компоненты (CLR сборки) и использовать их как "родные" элементы конфигурации, нет возможности.

"Порадовал" неоднокартно AxaptaComConnector невозможностью получать данные запросом по нескольким связанным таблицам и условиям по нескольким же...
По использованию .NET: как "родные" подключать не получитя, но как "очень близкие" никаких проблем :-) Первое - это технология создания внешних компонент, второе - уже существующая (сторонняя) оболочка, для подключения .NET компонент, написанных без использования вышеуказанной технологии.

Цитата:

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

1. Отсутствие возможности параллельной разработки нескольких программистов в одной конфигурации и одной базе. Как мне кажется, на больших проектах это сильно усложняет регламент разработки.

в одной базе? нет, в одной базе нельзя... Можно только с одним хранилищем :-)
Хм... я, кстати так и не разобрался как реагирует Axapta на изменение структуры таблиц без отключения пользователей...

Цитата:

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

3. Как я понял в типовых конфигурациях повсеместно используется подход - реализация бизнес-логики на модулях форм.

Не помню я такого в последних типовых - все реализуется в общих модулях, часть из которых выполняется исключительно на сервере (это о 8.1)
А в 8.2 особо не пропишешь бизнес логику в управляемых формах из-за определенных ограничений в возможностях доступа к объектам :-)))

Цитата:

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

4. Не реляционная структура БД.
Спорный, кончено, момент. Но, ИМХО, на данный момент существующие технологии объектно-реляционного преобразования не позволяют достичь такой же производительности, как если бы структура была чисто реляционной.
+ мы теряем возможность полноценного использования некоторых встроенных в СУБД средств оптимизации (partitioning напрмер) и аудита (трейсинг тяжелых запросов например) производительности.

Ох! А за это я сам готов разорвать разработчиков 1С!