Показать сообщение отдельно
Старый 05.04.2010, 22:34   #13  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
По поводу интеграции - мне кажется, на эту тему более чем исчерпывающе выразились тут: Peter Villadsen and Gustavo Plancarte: X++ to MSIL
Цитата:
Люди часто повторяют: надо стоять на плечах гигантов, и, думаю, в вашей студии это звучало не раз, но я чувствую, что это именно то, что мы должны делать. Нам не следует самим нести все затраты, связанные с поддержкой и развитием всей инфраструктуры, когда есть такие отличные вещи, как .NET, и Visual Studio, и LINQ.
Просто изначально в ядре Аксапты было реализовано много такого, что является совершенно самостоятельными продуктами у того же Ms, и тут возникает вопрос: либо дублировать разработку одних и тех же вещей, явно проигрывая с точки зрения возможностей в случае "изобретения велосипедов" для Аксапты, либо заменить встроенные в нее "велосипеды" интеграцией с самостоятельными продуктами, службами, технологиями. Среди таких "велосипедов" можно отметить:
  • собственный протокол AOCP, заменный на RPC;
  • собственный механизм аутентификации пользователей и шифрования их паролей, заменный на Windows-аутентификацию;
  • собственный механизм управления всеми настроенными на машине AOS'ами (к слову, дырявый с точки зрения безопасности), замененный на стандартные виндовые сервисы;
  • собственный формат БД для хранения приложения, замененный в 6-й версии на БД Ms SQL Server;
  • собственный движок справки, замененный на HtmlHelp;
  • собственный "движок" для корпоративного портала, замененный на Sharepoint;
  • собственная среда разработки, часть функций которой плавно переходит в Visual Studio;
  • собственный интерпретатор собственного же байт-кода, которые экспериментально заменяется на IL и CLR;
  • собственный движок отчетов, местами противоречивый с точки зрения архитектуры и в прошлом явно неоднократно приспосабливаемый под какие-то частные задачи, а теперь постепенно уступающий место SSRS
В общем, когда разработку ведет сторонняя контора, не контролирующая платформу и технологии, которые используются ее продуктом, то логично сделать продукт в значительной степени самодостаточным, но когда разработку начинает вести компания, которая разрабатывает и платформу, и СУБД, и все сопутствующие технологии, то логично не дублировать все эти возможности в отдельно взятом продукте, а интегрировать его с тем, что уже есть и работает.
А по поводу утяжеления клиента и повышения требований к каналам... можно вспомнить того же Джоэла Спольски:
Цитата:
Разработчики, которые прикладывают много усилий в оптимизацию и делают компактные и быстрые программы, однажды проснутся и обнаружат, что усилия были потрачены зря в большей или меньшей степени. Или, в крайнем случае, можно сказать, что «это не дало конкурентного преимущества в долгосрочной перспективе», если вы человек, разговаривающий как экономист.
Разработчики, которые наплевали на производительность и ринулись добавлять классные функции в свои программы, получат в долгосрочной перспективе лучшие программы.
За это сообщение автора поблагодарили: mazzy (2), Poleax (1).