|
|
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Дмитрий Сорокин А как бы вы предложили дальше поддерживать развивать систему, установленную на 30 заводах (около 3000 рабочих мест, суммарно - почти 1 ТБ накопленных данных), живущую уже 10 лет, постоянно дописываемую, с чистой клиент-серверной архитектурой (тонкий клиент), с миллионами строчек кода, тысячами таблиц и хранимых процедур, с модулями написаннами и на Delphi (от 3.0 до 5.0) и на Access (от 2.0 до 2000) и на VB и на С# и на Excel? Где каждый программист норовил написать собственный ОРМ или на крайний случай хотя бы бы свою библиотеку? С моей точки зрения подобная "объектизация" - единственный вариант рефакторинга сложной системы, имеющий шанс на успех. При таком подходе нет необходимости переписывать все заново - в теории надо лишь описать имеющиеся бизнес-объекты и бизнес-превила в метаданных и получить работающую систему (а заодно и бизнес-модель системы) Не совсем понял. У вас физически одна СУБД с 3000 клиентов написанных на целом зоопарке технологий? Или это несколько однотипных СУБД с примерно 100 клиентами на завод и возможно некой центральной СУБД куда стекается информация для консолидации? В любом случае вопросы такого масштаба как у вас, имхо не решаются на технологическом уровне. Расширяемость систем такого масштаба решается не на уровне объектной обертки. Это скорее вопрос к аналитикам, к правильности их видения места системы в контексте предприятия и стратегии её развития в терминах бизнеса. Эти вопросы никак не связаны с технологиями реализации системы. Мне очень слабо верится, что с появлением объектной обертки начнется "самоорганизация" системы "снизу", скорее это закочится если не хаосом, то очень серьезным усложнением и без того сложного. Если говорить чисто техически, то делая объектную обертку вы сразу попадаете на необходимость одномоментной замены десятка разновидностей клиентских приложений - что есть процесс болезненный и трудоёмкий. Мне достаточно тяжело представить себе интеграцию клиента на Ацессе 2.0 с сервером приложений\либо даже просто с ин-процесс КОМ сервером, написанным на шарпе. На вашем месте я бы шел эволюционным путем, вместо революционных переделок. Рефакторил бы СУБД. Вложился в документацию. Занялся бы системой обучения новичков. Выстроил бы процесс управления конфигурацией. Параллельно с этим я бы попытался постепенно уменьшить количество особей в зоопарке клиентских приложений, начиная с наиболее допотопных\проблемных, чтобы прийти хоть к какому-то единообразию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:40 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Дмитрий Сорокин tygra автор- свой механизм транзакций - все изменения вначале записываются в некий пул изменений, измененные объекты лочатся, затем по коммиту все изменения проводятся в БД. Неужели вы сделали это лучше, чем в MS SQL?!!! Вах! SQL транзакции не предполагают "протяженности во времени", они должны быть настолько короткими, насколько возможно. Представьте себе, что вы, открыв форму, посылаете серверу BEGIN TRAN, потом что-то там делаете в БД, а потом при нажатии на OK посылаете COMMIT или при нажатии на CANCEL посылаете ROLLBACK. Не буду объяснять недостатков подобного подхода. У нас есть свой механизм транзакций. Для изменения объектов надо начать такую транзакцию. Упрощенно говоря - при изменении объектов изменения накапливаются, измененные объекты "лочатся" (нашими средствами), при коммите такой транзакции все накопившиеся изменения "накатываются" на SQL сервер, при отмене транзакции - просто объекты возвращаются в состояние "до начала транзакции". До закрытия транзакции есть возможность делать UNDO. Изобретаете велосипед? И почему транзакции не могут быть растянутыми во времени? Представьте себе, ваш апп сервер залочил запись в БД... и не разлочил... Как бороться будете? В СУБД можно посмотреть кто и как залочил запись(в случае СКЛ-сервера лочятся сразу страницы), и прибить его соединение. В вашем случае увидим, запись залочил апп-сервер.... и что дальше? Рестарт апп-сервера? Со стороны СУБД и сопровождения системы в целом, такая не тривиальная(почти всегда очень кривая) работа с базой приводит к огромным проблемам... и невилирует все красивости диаграмм и кода на клиенте. И люди, которые обычно пишут такие системы, потом насилуют кривоватый апп-сервер чтобы оно хоть как-то работало. В результате обычно все маппинг тулы забиваются СУБД зависимыми СКЛ-запросами ... ИМХО, не надо совмещать то что плохо совместимо... хотите обьекты - не берите РСУБД .... возьмите ООСУБД ..., она в такую логику вписываеться на 100% .... Зачем над РСУБД издеваться....? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 17:14 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
TerroristИзобретаете велосипед? И почему транзакции не могут быть растянутыми во времени? Представьте себе, ваш апп сервер залочил запись в БД... и не разлочил... Как бороться будете? Нет у нас сервера приложений! Ну НЕТУ ЕГО!!! Что же все приписывают нам изобретение сервера приложений! И на сервере ничего не лочится! Это наши личные локи. Это же все много раз проходили: создаете табличку, записываете туда ID объектов, которые редактируете, когда редактирование завершено - стираете оттуда. Плюс сборщик мусора. (Все не совсем так, но по сути - верно) DrKonito Не совсем понял. У вас физически одна СУБД с 3000 клиентов написанных на целом зоопарке технологий? Или это несколько однотипных СУБД с примерно 100 клиентами на завод и возможно некой центральной СУБД куда стекается информация для консолидации? В любом случае вопросы такого масштаба как у вас, имхо не решаются на технологическом уровне. Расширяемость систем такого масштаба решается не на уровне объектной обертки. Это скорее вопрос к аналитикам, к правильности их видения места системы в контексте предприятия и стратегии её развития в терминах бизнеса. Эти вопросы никак не связаны с технологиями реализации системы. Мне очень слабо верится, что с появлением объектной обертки начнется "самоорганизация" системы "снизу", скорее это закочится если не хаосом, то очень серьезным усложнением и без того сложного. Баз у нас множество. Минимум - по одной - на инсталляцию. Плюс - консолидирующие базы. Плюс - разные служебные базы. 3000 клиентов - это общее число пользователей, работающих с системой. Максимальное число одновременных пользователей на 1 базе - 600, размер этой базы - 300Гб. Речь не идет о расширяемости - скорость нас вполне удовлетворяет. Речь идет о том, что система стала чересчур "сложной", что ее архитектура устарела, что развивать систему становится все сложнее и сложнее. Я уверен, что это болезнь всех классических двухслойных архитектур. ИМХО- с ростом сложности таких систем резко возрастают затраты на их поддержку и дальнейшее развитие, и именно в этом и состоит главное преимущество многослойных архитектур. Средний слой мы не хотим применять в принципе - лишние затраты для достижения той же производительности, да и масштабы рефакторинга слишком велики. Мое глубокое убеждение - применяемый нами "объектный" подход, при формальном сохранении двухслойности, позволяет получить все архитектурные преимущества многослойных систем с гораздо меньшими затратами. Повторяю - все сказанное есть ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 20:08 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
ACRUS За 3 месяца этот инструмент был реализован, с возможностью аналитикам рисовать на деревьях различные схемы учета движения финансов, вешать различные правила заполнения документов и мониторинга финансовых потоков (правила расширяемые, представлены как SQL-батчи, вешаются на ноды с возможностью их наследования дочерними нодами и выполняются в БД), вешать различные схемы учета на разные предприятия и в разных учетных периодах, а так же вести централизованное управление, администрирование и апгрейт всех РСУБД удаленных узлов, вплоть до удаленного выполнения SQL-скриптов на указанных узлах, с контролем состояния их выполнения. Было бы очень забавно посмотреть, как за такое время, можно было бы такую же функциональность, да еще и работающую, на принципах ООП сделать. Я уже приводил пример MFC-шника. Конечно, если у вас мегабайты наработанного кода для вашей СУБД, то вы сделаете такой проект быстро и качественно. И я не кого не призываю все бросить и переписать сущетсвующий код на обертках и т.п. - просто оба подхода имеют право на существование и могут быть лучше или хуже в зависимости от конкретного приложения и конкретной команды разработчиков. Критерий же хорошего проектирования и процесса разработки у меня простой - прибыль, полученная от продажи и сопровождения продукта. Остальное - сложность создания среднего слоя, прелести использования SQL для всей бизнес-логики или ООП - домыслы и размышления, которые проверить невозможно. Каждая команда использует знакомые ей средства разработки и существующие наработки в той области, на которой они специализируются. А обвинить в кривости рук, незнании какой-то фишки в конкретной СУБД и неумении проектировать можно всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 20:14 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
авторЯ уже приводил пример MFC-шника. Конечно, если у вас мегабайты наработанного кода для вашей СУБД, то вы сделаете такой проект быстро и качественно. И я не кого не призываю все бросить и переписать сущетсвующий код на обертках и т.п. - просто оба подхода имеют право на существование и могут быть лучше или хуже в зависимости от конкретного приложения и конкретной команды разработчиков. Да нет у меня мегабайтов кода Есть нормальная адекватная РСУБД и платформа для построения клиентской части, которые изначально позволяют делать все описанное. Остается только воспользоваться этими возможностями и поверх сделать адекватный код управления логикой и визуального администрирования, который так же занимает копейки. Это говорит не о подходах, а о выборе платформе - к примеру какой бы подход я не взял, реализация того же самого на базе MSSQL+Delphi действительно заняла бы в десятки раз больше времени, получилось бы в десятки раз больше кода (с меньшим кол-вом возможностей) и действительно были бы мегабайты кода. Ну и естественно самым важным на любой платформе и любом подходе является опыт архитектора проекта, это самый первый пункт в рисках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 22:36 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Ну про MSSQL+Delphi и мегабайты коды + и т.д. вы уж загнули Там тоже нет этого всего - те же копейки. Ну может десятки копеек. :) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 12:07 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
tygraНу про MSSQL+Delphi и мегабайты коды + и т.д. вы уж загнули Там тоже нет этого всего - те же копейки. Ну может десятки копеек. :) -- Tygra's -- Мегабайты, мегабайты - говорю не просто так, а с реального опыта :) Сначала были проекты на MSSQL+Delphi, теперь проекты на ASA+PB, разница в коде очень значительная, причем последние проекты по обьему и функционалу поболее будут. На ASA многие вещи с учетом более большой функциональности решаются враз, где на MSSQL приходится или выкручиватся или же вообще скидывать на клиентскую часть. На Delphi даже с теми же компонентами DevExpress кода работы логики с интерфейсом не мало получалось (это с учетом того, что своих компонент на все случаи жизни еще порядка 50 было и куча шаблонов форм и классов), на PB реально все покрывает DataWindow + собственная не очень большая иерархия классов и форм, фактически остается только мышкой DataWindow источники данных и их визуализацию рисовать и где нужно парой строчек кода в отнаследованных обьектах приватную логику описывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 12:55 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Может вы чего-то такое особенное писали - не вижу никаких мегабайтов кода у себя. В общем случае - пара процедур в модуле и все. DevExpress не используем - тока EhLib. Это нужно не тут и поконкретнее разговаривать - что вы делали, что мы, и как реализуется. Я уже писал - несколько минут на добавление основных форм для таблицы. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:00 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
DataWindow сильный плюс PB. Жалко, что нет хотя бы близких по функционалу компонентов для дельфей. Что касается самой среды и модели классов, то мне не совсем она нравиться. Но, не будем об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:21 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
pkarklin Сама среда PB действительно хреновенькая, модель классов своя и достаточно простенькая, точно на уровне - ровно столько, сколько нужно для хорошей жизни без заморочек и кода. PFC вообще не пользуемся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:25 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Извиняюсь перед сообществом, за оживление умершего 1.5 года назад флейма. Но не могу не похвастаться. DrKonito tygraИ что оно там узнает? Надо мягко ему рассказывать, как БЛ на сервере объеденить с тем, чего они услышали, дополнить всеми плюсами БЛ на сервере - и все будет хорошо. :)) А что за семинары то? Где там микрософт предлагает БЛ где-то в другом месте? -- Tygra's -- Оно приходит набравшись слов типа апп-пулинг, ван-клик-деплоймент, компоненты, мнгозвенные приложения, НЕТ-Фреймворк, НЕТ-Фреймворк, НЕТ-Фреймворк ... Т.к половины этих слов оно не понимает, а слов про бизнес-логику на транзакте там не говорилось, то ход его мыслей примерно таков- написать все на НЕТ и все будет зашибись - об остальном Микрософт позаботится. Соответсвенно вооружившись такой стратегией начальство набрало несколько человек, которые на собеседовании говорили похожие слова. Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :) Со своей стороны я пытаюсь продавить позицию, что логика должна быть хотя бы на сервере. В каком виде - это вопрос открытый. Наверное веб-сервисы не самое худшее, что может случиться, учитывая сложившуюся ситуацию :). Проект по переписыванию бизнес-логики на шарпе успешно загнулся в прошлом месяце. Основная причина - сложность интеграции с остальной системой. Т.е. фактически единственным способом перейти на МегаТрёхзвеннуюАрхитектуру "неожиданно" оказалось переписывание всей системы с нуля. Идеолог уволен. Потрачено около человеко-года трудозатрат. Делайте выводы сами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 09:04 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
DrKonitoНо не могу не похвастаться. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 10:07 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Блин...... Читал 2,5 часа. ниасилил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2007, 17:10 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
DrKonitoПотрачено около человеко-года трудозатрат. Легко отделалась. С момента появления СУБД все схемы - это клиент-сервер и никаких многозвенок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2007, 09:57 |
|
||
|
Создание сервера приложений
|
|||
|---|---|---|---|
|
#18+
Простой рабочийСпасибо всем за отзывы. Извиняюсь за задержку, вчера весь день провёл на конференции. tygra авторДвухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений? А вам зачем трехзвенное? Просто так или делать нечего? :)) -- Tygra's -- У компании открываются отделения в других городах и есть потребность контролировать информацию на местах. Тонкий клиент с отдельным сервером приложений - как раз выход из ситуации. Второй момент - переложить всю логику на сервер, тем самым увеличив скорость проведения документов или формирования отчетов. Хорошее предложение поступило насчет хп сервера, но это, ИМХО, удобно реализуемо только на MS SQL Server 2005 (из линейки майкрософт). В филиалах лучше поставить отдельные серверы БД и настроить репликации. Если даже каналы упадут, работа будет возможна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2007, 01:48 |
|
||
|
|
start [/forum/topic.php?fid=33&msg=33332858&tid=1548944]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
116ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 470ms |
| 0 / 0 |
