|
![]() |
#1 |
Участник
|
"На этой карете прошлого далеко не уедешь"
![]() А вот тут как я понимаю у 1С как раз все не очень здорово. Точно знаю, что платформа 8.1 не может выступать сама как .NET провайдер. И похоже, что внутри нее подключить .NET компоненты (CLR сборки) и использовать их как "родные" элементы конфигурации, нет возможности. + что, еще разочаровало в платформе 8.1: 1. Отсутствие возможности параллельной разработки нескольких программистов в одной конфигурации и одной базе. Как мне кажется, на больших проектах это сильно усложняет регламент разработки. + сюда же - необходимость перезапуска клиента 1С для того, чтобы протестировать изменения в конфигурации (что тоже скорости разработки не добавляет). 2. Отсутствие полноценного наследования и остальных атрибутов настоящего ООП. При проектировании новой сложной функциональности (как сам MS, так и партнеры) могут использовать все современные методики проектирования ПО опираясь на общепринятую терминологию (ООП паттерны (GOF, Фаулер), рефакторинг, UML и т.п.). Какие методики при проектировании архитектуры масштабных решений (на их самобытном фреймворке) использует 1С мне не очень понятно. 3. Как я понял в типовых конфигурациях повсеместно используется подход - реализация бизнес-логики на модулях форм. Как мне кажется, связано это с пунктом 2. От этого, "детские болезни", о которых писал mazzy (бешеный траффик между клиентом и АОС-ом и т.п.) становятся совсем недетскими ![]() Поэтому, чтобы вылечить эти "детские болезни", скорей всего потребуется тотальное переписывание типовых конфигураций. А это означает, что клиентам 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С же по сути внедряли с нуля в течении года (хотя там были проблемы с менеджментом проекта, но тем не менее). |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#2 |
Участник
|
Цитата:
Хоть 50 программистов подключай. Соглашусь. Скорее всего именно так и будет. Кормушка открыта, господа. |
|
|
За это сообщение автора поблагодарили: Hans (1). |
![]() |
#3 |
Участник
|
Цитата:
1С вполне самодостаточный продукт. я думаю у них хватит сил чтоб не использовать чужие наработки. А создать что-то своё, более удобное и компактное.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
![]() |
#4 |
1C
|
Цитата:
Сообщение от SolNik
![]() "На этой карете прошлого далеко не уедешь"
![]() А вот тут как я понимаю у 1С как раз все не очень здорово. Точно знаю, что платформа 8.1 не может выступать сама как .NET провайдер. И похоже, что внутри нее подключить .NET компоненты (CLR сборки) и использовать их как "родные" элементы конфигурации, нет возможности. По использованию .NET: как "родные" подключать не получитя, но как "очень близкие" никаких проблем :-) Первое - это технология создания внешних компонент, второе - уже существующая (сторонняя) оболочка, для подключения .NET компонент, написанных без использования вышеуказанной технологии. Цитата:
Хм... я, кстати так и не разобрался как реагирует Axapta на изменение структуры таблиц без отключения пользователей... Цитата:
А в 8.2 особо не пропишешь бизнес логику в управляемых формах из-за определенных ограничений в возможностях доступа к объектам :-))) Цитата:
Сообщение от SolNik
![]() 4. Не реляционная структура БД.
Спорный, кончено, момент. Но, ИМХО, на данный момент существующие технологии объектно-реляционного преобразования не позволяют достичь такой же производительности, как если бы структура была чисто реляционной. + мы теряем возможность полноценного использования некоторых встроенных в СУБД средств оптимизации (partitioning напрмер) и аудита (трейсинг тяжелых запросов например) производительности. |
|
![]() |
#5 |
Moderator
|
![]() Цитата:
Буквально летом пришлось модифицировать отчет в 1С 8.1 - просто убила куча кода наваленная в одном месте и никак не разбитая на просто напрашивающиеся логические куски или блоки.
__________________
С уважением, kvan. |
|
![]() |
#6 |
Участник
|
Цитата:
По крайней мере, модули проведения документов (постинг) в последних версиях типовых написаны очень грамотно с точки зрения быстродействия и использования библиотек. И управляемые блокировки используются. Другое дело, что MS начал этот путь лет на 7-8 раньше ![]() |
|
![]() |
#7 |
Moderator
|
Очень сомневаюсь около 300 строк кода специально свалили в одно место, в аксапте это можно разбить как минимум на методы внутри отчета.
__________________
С уважением, kvan. |
|
![]() |
#8 |
Участник
|
Да, 300 строк без разбиения - это жестоко.
|
|
Теги |
1c, платформа, сравнение систем |
|
|