Прошу поделиться опытом в Web-проектировании.

← →
vuk © (2006-10-24 12:35) [40]

to Курдль © (24.10.06 12:29) [39]:
>НО!!!! Она ни в какие рамки по производительности не укладывается.
От то-то и оно. С Cache, если не ошибаюсь, та же история. Гладко было на бумаге...

← →
Игорь Шевченко © (2006-10-24 12:37) [41]

Курдль © (24.10.06 12:29) [39]

> А зачем оно нужно? Чем меньше делений кода приложения на
> клиентский/серверный/СУБД-шный по размещению, или скриптовый/ООП-
> ный/процедурный по технологиям, тем проще процесс разработки.
> Где я не прав?

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

> Если я смогу исполнить всю бизнес-логику системы, включая
> хранение данных, в едином средстве/стиле/модели

Так серебряной пули все равно нет, еще Брукс писал :)

> > Да только вот где они, эти ООБД?
>
> Навскидку вспомню 2: Cache и Versant.
> Я уже делился впечатлениями от работы с последней - это
> волшебство!
> НО!!!! Она ни в какие рамки по производительности не укладывается.
> Вот поэтому я и заявляю, что пока мы в плену у не поспевающих
> технологий.

Я вот в свое время на Turbo C программки писал...Лет эдак восемнадцать назад. Я к чему - у меня от Visual Studio тоже неплохие впечатления, но производительность, она тоже несильно укладывается по сравнению с Turbo C :)

← →
Курдль © (2006-10-24 12:45) [42]

> Игорь Шевченко © (24.10.06 12:37) [41]
> Так простота процесса разработки это не главный критерий.
> Разделение на клиентский и серверный код диктуется еще
> и соображениями производительности, не так ли ?

Уже не знаю!!! :) Взрослею, что ли! Если я смогу сделать за полгода продукт с ошеломительной производительностью, или за 3 месяца с приемлемой для заказчика, то я выберу последнее!

> > Если я смогу исполнить всю бизнес-логику системы, включая
> > хранение данных, в едином средстве/стиле/модели
> Так серебряной пули все равно нет, еще Брукс писал :)

Я имею опыт исполнения 2-х крупных проектов на бизнес логике, исполненной в сервере приложений, а не на СУБД. Готов долго рассказывать о выигрыше, полученном при таком подходе.

← →
Danilka © (2006-10-24 12:58) [43]

[42] Курдль © (24.10.06 12:45)
> Готов долго рассказывать о выигрыше, полученном при таком
> подходе.

Расскажи, только желательно не очень долго. :)

← →
Игорь Шевченко © (2006-10-24 13:06) [44]

Курдль © (24.10.06 12:45) [42]

> Уже не знаю!!! :) Взрослею, что ли! Если я смогу сделать
> за полгода продукт с ошеломительной производительностью,
> или за 3 месяца с приемлемой для заказчика, то я выберу
> последнее!

Заказчик заказчику люпус эст. Если для каждого заказчика тратить три месяца на приемлемое для него решение, то я выберу путь за полгода удовлетворяющий потенциально разных заказчиков.

> Я имею опыт исполнения 2-х крупных проектов на бизнес логике,
> исполненной в сервере приложений, а не на СУБД. Готов долго
> рассказывать о выигрыше, полученном при таком подходе.

Было бы интересно послушать, тем более, имея похожий опыт могу рассказать о проигрыше.

← →
saxon (2006-10-24 13:21) [45]

> Курдль © (24.10.06 12:29) [39]
> Чем меньше делений кода приложения на
> клиентский/серверный/СУБД-шный по размещению, или скриптовый/ООП-
> ный/процедурный по технологиям, тем проще процесс разработки.
> Где я не прав?

А в чем простота? К примеру, проще поменять логику в хп и - апдейт ее, чем в коде и потом еще перекомпилировать, переустанавливать, .....

> Если я смогу сделать за полгода продукт
> с ошеломительной производительностью, или за 3 месяца с
> приемлемой для заказчика, то я выберу последнее!

Почему такая разница? На что собственно 3 месяца пропало?

← →
Petr V.Abramov (2006-10-24 13:25) [46]

> Игорь Шевченко © (24.10.06 13:06) [44]
присоединяюсь к вопросу.
> Курдль ©
давай рассказывай! :)))

> Да только вот где они, эти ООБД?
на букву О последние версии неплохо работают

← →
Petr V.Abramov (2006-10-24 13:31) [47]

> Разделение на клиентский и серверный код диктуется еще
> и соображениями производительности, не так ли ?
в основном из соображений, что для манипуляции данными хорошо подходят одни языки/технологии, а для рисования интерфейса - другие.

← →
Lamer@fools.ua © (2006-10-24 13:32) [48]

>Думаю, что ООБД сменят РСУБД в ближайшее время.

Это я ещё пару лет назад на sql.ru читал.

← →
Курдль © (2006-10-24 13:47) [49]

Опасаюсь, что погрязну в обоснованиях... Но все равно начну.
Сначала, надеюсь, закроем тему скриптов и ООП. Если говорить о создании сайтов, и прочих вэб-ориентированных изделий, то в VS2005 уже приблизились вплотную к унификации создания любых приложений. Сделав выбор "Вэб проект" в начале разработки я получаю все тот же привычный инструментарий + некоторое количество специфических компонентов. Разметку страниц могу создавать все в том же дизайнере, в котором готовил оконные формы. Не отделаться пока от проблем, связанных с работой браузеров (предмет моей печали всего этого топика). Кто-то имеет что-то против такой тенденции унификации?
Так же и в БД-ориентированных приложениях хотелось бы навсегда забыть о PL/SQL, TSQL и т.п. специфических инструментах. (Кстати, Sybase представляет возможность программирования серверной логики на Java).
Если начинать спор о опльзе "ХП-программирования", наверное надо как-то разложить по пунктам их пользу и вред. Вот это я хочу возложить на своих опонентов. Вопрос: какие по-вашему задачи следует решать именно на ХП?

← →
vuk © (2006-10-24 14:23) [50]

to Petr V.Abramov (24.10.06 13:25) [46]:
>на букву О последние версии неплохо работают
На букву О таки является РСУБД.

← →
iZEN © (2006-10-24 14:42) [51]

> Курдль © (23.10.06 15:34)
>
> Решил я для ликвидировать собственную безграмотность в этой
> области. (Пока время позволяет).
> Интересует меня следующая информация - технологии и их отличия.
> Наибольший интерес представляют технологии создания тонких
> клиентов.

Прочти: http://www.techinfo.net.ru/docs/web/javawebdev.html

← →
_dimka © (2006-10-25 10:30) [52]

> Разница простая! У меня есть великолепный инструмент для
> создания приложений - VS2005. (или Delphi, или Java Builder)
> . Этот инструмент создан с учетом лучших достижений в IT,
> которые подразумевают использование ООП, паттернов, UML
> и т.п. И вдруг для какой-то части разрабатываемой мною системы
> (напр. тонкого клиента, или серверной логики БД) я должен
> переключаться на корявые скрипты или процедурные языки СУБД.
> Либо должен содержать в команде специальных разработчиков
> - узких спсслистов по этим атавизмам.

Вас никто не заставляет "переключаться на корявые скрипты", AJAX это всего лиш технология асинхроной загрузки страницы, а как Вы это реализуете, криво или нет, это Ваши проблемы... Вы можете использовать ООП и в JavaScript.

← →
Игорь Шевченко © (2006-10-25 10:41) [53]

Курдль © (24.10.06 13:47) [49]

> (Кстати, Sybase представляет возможность программирования
> серверной логики на Java).

Oracle тоже поддерживает программирование серверной логики на Java.

А MS SQL 2005 - так и вовсе на любом из языков, поддерживающих .Net (или CLR, что несущественно).

> Вот это я хочу возложить на своих опонентов. Вопрос: какие
> по-вашему задачи следует решать именно на ХП?

Например, минимизация обмена данными между клиентом и сервером, снижение нагрузки на сеть - это вроде очевидная задача. Разграничение доступа - еще одна.

← →
Курдль © (2006-10-25 10:48) [54]

> _dimka © (25.10.06 10:30) [52]
> Вас никто не заставляет "переключаться на корявые скрипты",
> AJAX это всего лиш технология асинхроной загрузки страницы,
> а как Вы это реализуете, криво или нет, это Ваши проблемы.
> .. Вы можете использовать ООП и в JavaScript.

Да, но при этом часть проекта будет на JavaScript, часть - на С#, а часть - на PL/SQL.
Я надеюсь, что скоро удастся весь проект вести в какой-либо одной среде и на одном языке.
Лично мне не трудно освоить JavaScript, как в свое время PL/SQL, меня лично это даже забавляет. Но с точки зрения IT индустрии это вредно.

← →
Danilka © (2006-10-25 11:18) [55]

[54] Курдль © (25.10.06 10:48)
> Но с точки зрения IT индустрии это вредно.

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

← →
Курдль © (2006-10-25 11:32) [56]

> Danilka © (25.10.06 11:18) [55]

Я вовсе не имею в виду "одиночные разработки". И сам уже давно работаю только в группе. Однако, считаю разделение разработки на узко-специальные участки непозволительной роскошью для небольших IT-компаний. В противном случае надо иметь в штате гениального архитектора, имеющего огромный опыт в большом количестве разработок и способного точно и быстро составлять ТЗ для каждого специалиста.

← →
WondeRu at work (2006-10-25 12:26) [57]

> Курдль © (23.10.06 15:34)

можно делать все на одном языке - C#, вот связка:
server: ASP.NET 2.0
client: Atlas (atlas.asp.net) - не спрашивай что такое, там написано
DB access: LINQ

← →
Sergey Masloff (2006-10-25 21:31) [58]

WondeRu at work (25.10.06 12:26) [57]
>можно делать все на одном языке - C#, вот связка:
Со сложностью клиентского представления немногим более сложным чем блокнот? ;-)

← →
Sergey Masloff (2006-10-25 22:32) [59]

Курдль © (25.10.06 11:32) [56]
>Я вовсе не имею в виду "одиночные разработки". И сам уже давно работаю >только в группе. Однако, считаю разделение разработки на узко->специальные участки непозволительной роскошью для небольших IT->компаний. В противном случае надо иметь в штате гениального >архитектора, имеющего огромный опыт в большом количестве разработок и >способного точно и быстро составлять ТЗ для каждого специалиста.
Да участков-то всего два. Сервер и морды к нему. И никаких гениев не нужно. Просто несколько нормальных спецов продумывают "ядро" - "сервер приложений" и гибкую структуру хранения в базе а вокруг этого рисуются клиенты. И никаких гениальных архитекторов не надо.
А в результате имеем неизменное ядро уже 10 лет. Гипотетическая компания с тех пор выросла по штату в 10 раз по обороту раз в 30 (год назад было пара-тройка млн. у.е. в день сведения из открытых источников) и при этом масштабирование сугубо линейное. Покупается железо помощней и все. Причем буржуйский IT аудит от акционеров подтвердил скрепя сердце что резерв десятикратного масштабирования в системе есть и на настоящий момент. Работает "толстый" клиент "средний" с https сервером приложений для региональной сети, а также несколько десятков (если не сотен) шлюзов к информационным системам партнеров. При изменении бизнес-логики правится в ОДНОМ месте код на сервере и ВСЕ клиенты тут же работают по новым правилам. Ку?

← →
Sergey Masloff (2006-10-25 22:45) [60]

Впрочем, позицию Курдль © я, в принципе, понимаю. Он смотрит с точки зрения софтвер-хауза. Что там нужно - максимально быстро и с оптимальными затратами собрать под заказчика работающий продукт. Пусть не оптимальный но с приемлемым соотношением цена-качество. После чего продать его, получить баблосы и думать о новых проектах. При возникновении у клиента новых проблем не оговореных контрактом нет проблем новый контракт, а тут у нас как раз новый инструментарий, супер пупер нечто 2015 и самый быстрый и производительный сервер ххх в новой редакции старое иксуем новое пишем бабки берем все счастливы.
В принципе, ээто часть IT индустрии и имеет право на жизнь. Для такой конфигурации подход Курдля вполне разумен и, я уверен, эффективен.
Другую (не противоборствующую - а сосуществующую) когорту со своими взглядами представляют в данном случае я, vuk и Игорь Шевченко (ребят простите что я в ваш калашный ряд мастеров со свиным рылом лезу но тут концептуальное единство) к примеру. Которые смотрят на это дело глазами заказчика так как работают на него а не на софтвер-хаус. И часто проблемы заказчика и их решение предвидят даже когда он об этом не думает. И когда переделка при изменении требований светит не новыми контрактами а сверхурочной работой и головной болью. И там как-то стараешься побольше на сервер взвалить так как явы и дотнеты приходят и уходят а реляционка она ужо 20 лет реляционка и только лучше становится.
И оракл можно любить не за гипотетическую надежную и быструю молотилку (которая еще и побыстрей и понадежней есть и примеры я приводил Курдлю ;-))) а за удобные и действительно надежные средства реализации бизнес логики. За аналитические функции, за PL/SQL и подобный фаршпак.
Я не говорю что мы умнее или наоборот. Просто разные среды сформировали различные подходы. И те и другие работают. В разных условиях по-разному. Ну и что - все нормально. Главное не запудривать головы начинающим что что-то одно верно ;-))))

> Sergey Masloff (25.10.06 22:45) [60]
> Впрочем, позицию Курдль © я, в принципе, понимаю. Он смотрит
> с точки зрения софтвер-хауза. Что там нужно - максимально
> быстро и с оптимальными затратами собрать под заказчика
> работающий продукт. Пусть не оптимальный но с приемлемым
> соотношением цена-качество. После чего продать его, получить
> баблосы и думать о новых проектах.

В принципе, такое мнение о моих помыслах имеет право на жизнь. Однако, спешу Вас заверить, что я такой же белый и пушистый, как Вы и упомянутые Вами глобалы мысли. Мне не чужды бессонные бдения над вопросами оптимизации. И материальные результаты исполнения проекта не затмевают гордости за хорошо выполненную работу.

Речь не о том. И уж вовсе не для начинающих эта ветка. Она, в частности, стала следствием моего интереса к ASP.NET, подогретого заявлением дружественной компании о завершении крупного проекта корпоративной автоматизации, в котором рабочие места специалистов "исполняются" браузером.

А в общем, хочется научиться быстро и качественно создавать по-настоящему робастные системы. И найти под это стремление оптимальные технологии - естественное стремление.
Только с переходом на ДотНет я впервые почувствовал, например, силу "повторного использования кода". До этого были лишь робкие попытки. Я неспроста окунулся в глубокое изучение UML и паттернов, методологии проектов и системной архитектуры. Пока что меня сильно беспокоит проблема "невписывания", например, JavaScript или процедурных языков СУБД в стройную теорию.
Но и какой-никакой опыт я имею. Этот опыт мне говорит, что бизнес-логика на сервере БД - это совершенно непригодная к тиражированию конструкция. Да и ее сопровождение дается непросто.

Кстати, по поводу "вечно живой реляционки" я бы тоже не зарекался.
Я предполагаю (и не только я), что есть не такая уж туманная перспектива перевода хранения данных оперативных систем на объектно-ориентированные СУБД, с последующей интеграцией их (данных) в корпоративные хранилища данных (которые с реляционными принципами рядом не валялись).

← →
Sergey Masloff (2006-10-26 05:59) [62]

Курдль © (26.10.06 01:15) [61]
Я, как обычно, неправильно понят. Сначала тезисно. Несмотря на, возможно, не слишком подходящую терминологию ("баблосы" etc) мой пост НЕ подразумевал (честно) следующих идей
1) Курдль (далее для краткости К) менее белый и пушистый чем, скажем, я
2) Подход который он предлагает - ущербный
3) Он (подход) требует более низкой квалификации
4) Сам К только такой квалификацией и обладает
5) Он (К) нечист на руку и думает только о том как срубить денег и на проблемы клиента ему чихать

Еще раз повторю - все это НЕ подразумевалось.

Теперь к частностям. Давай про "крупность" проекта. Если это интернет-магазин то прекрасно, веб-интерфейс рулит. Но если это сложный функционал то как не крутись - ну не реализовать его через веб-интерфейс УДОБНО. А средства построения клиента работающего через браузер (и не менее мощные чем АСП дотнет были и 10 лет назад - Lotus IBM овский например). И проекты были, не меньшеие чем у дружественных фирм. Но все равно когда нужен мощный графический интерфейс браузер не годится. Если не встроить в него свое окно (апплет активикс что угодно) и не работать в нем. Но тогда на фига браузер берем свое окно без него и работаем.

>А в общем, хочется научиться быстро и качественно
Кто ж спорит. Только что-то мне кажется ты провалишься за оптимум пытаясь универсализовать все так сильно

>Но и какой-никакой опыт я имею. Этот опыт мне говорит, что бизнес->логика на сервере БД - это совершенно непригодная к тиражированию >конструкция.
Мой опыт говорит обратное. Но он не лучше или хуже, не больше или меньше - он просто другой. Да, перенести нашу систему на другой сервер нереально. Но уж если кто ее покупает может и оракл купить (сервер, не саму корпорацию конечно ;-))
А так тиражировали довольно успешно. И повторюсь - вот у нас шлюзов к системам партнеров с сотню наверное. Как их в одном сервере приложений реализовать я вообще не понимаю как в 100 разных логику одну поддерживать без централизации ее в БД... конечно теоретически можно представить но в реализации... А 101-й появится?

>Кстати, по поводу "вечно живой реляционки" я бы тоже не зарекался.
Да почему вечно? Но пока альтернатив не видно

>Я предполагаю (и не только я), что есть не такая уж туманная перспектива >перевода хранения данных оперативных систем на объектно->ориентированные СУБД,
Будем посмотреть. Это я слышал еще в конце 90-х. Тогда активно пиарилась некая объектная база (блин забыл название mumphs чтоли вобщем cashee это она же после ребрендинга. Физически это тот же движок только название поменяли так как то было дискредитировано). Пока ничего не поменялось а прошло уже 10 лет.

>с последующей интеграцией их (данных) в корпоративные хранилища >данных (которые с реляционными принципами рядом не валялись).
Это слишком сильное утверждение. Представление внешнее их на реляционноре непохоже но внутри-то. По крайней мере, на настоящий момент (и, думаю лет на 10 вперед еще - точно)

Впрочем, не исключаю что в будущем твой подход победит. Что же, прижмет - переучусь. Проблем-то особых нет.

P.S. Мне будет значительно комфортнее обращение на ты. Я конечно понимаю что все мы тут друг друга дико уважаем и все такое, будем считать что ненужные формальности соблюдены. OK?

P.P.S. Я отвечаю не очень интерактивно но после работы обязательно просмотрю. Ветка интересная.

> Sergey Masloff (26.10.06 05:59) [62]

Я считаю эту ветку необычайно продуктивной!!! Вряд ли я смог бы иным способом в столь сжатый срок получить такое количество полезной информации в виде по-настоящему толковых ссылок, мнений компетентных специалистов, примеров из богатого опыта и здравых рассуждений неординарных людей.
В части, касающейся моих исследований по ASP.NET я немного разочарован. Но исследования продолжу (не зря же я скупил целую полку книг в Библио-Глобусе :). Большие надежды возлагаю на рекомендованный мне в этой ветке Ajax. Результаты доложу.

Сейчас с удовольствием попробую поделиться приобретенным опытом в обсуждаемых вопросах.
Про тиражирование я неточно выразился. Я не имел в виду поставку уже созданной системы клиентам, желающим видеть в ней разные сервера БД.
Я имел в виду сложность переноса наработок в виде серверной логики, созданных для одного проекта, на другой проект. Причем последний вполне может оказаться из другой предметной области.

Про хранилища данных могу рассказать очень многое, т.к. именно сейчас этим занимаюсь. Однако надеюсь, что мой следующий проект не будет с ними связан (рутина). Так вот, хранилища реально не имеют никаких релэйшнов (разве что в модели) и констрэйнтов, а тем более триггеров и ХП т.к. целостность данных в них не является первостепенной задачей. Более того, некоторые специализированные сервера хранилищ (Sybase IQ) имеют чудовищную, для привыкших к реляционкам, технологию "харенения по столбцам, а не по записям". Но это позволяет давать любым другим средствам 10, а то и 100-кратную фору в производительности выборок.

ЗЫ: Сочту за честь перейти "на ты".

Курдль © (26.10.06 01:15) [61]

> Этот опыт мне говорит, что бизнес-логика на сервере БД -
> это совершенно непригодная к тиражированию конструкция.
> Да и ее сопровождение дается непросто.

Курдль © (26.10.06 10:19) [63]

> Я имел в виду сложность переноса наработок в виде серверной
> логики, созданных для одного проекта, на другой проект.
> Причем последний вполне может оказаться из другой предметной
> области.

Я опять же, извиняюсь, а разве клиентская часть в плане переноса в этом случае чем-то отличается от сервеной ?

Относительно повторного использования кода - могу сказать, опять же по собственному опыту, из по-настоящему универсальных решений на все случаи жизни у меня (как в личном программировании, так и в производстве) используются всего ТРИ класса (мною же написанных, разумеется). Хотя общее число написанных довольное большое.
Да, конечно, в ряде случаев более или менее совпадающих предметных областей это количество увеличивается, но так, чтобы использовать всегда и не думать - вот то самое озвученное число ТРИ.

Курдль © (24.10.06 12:00) [36]
Думаю, что ООБД сменят РСУБД в ближайшее время.

Уже лет 8, если не больше, такие возгласы раздаются.
А толку ?

← →
WondeRu at work (2006-10-26 11:22) [66]

Sergey Masloff (26.10.06 05:59) [62]

> Но тогда на фига браузер берем свое окно без него и работаем.

Согласен, фу его :)

2Курдль:
Еще советую посмотреть на Microsoft Smart Client, может пригодится в будущем

← →
saxon (2006-10-26 11:41) [67]

> В части, касающейся моих исследований по ASP.NET я немного
> разочарован.

И что тебя не устраивает?

> Большие надежды возлагаю на рекомендованный мне в этой ветке
> Ajax. Результаты доложу.

Использую (правда пока как Атлас) - хорошая шкута!

Прошу поделиться опытом в Web-проектировании. Найти похожие ветки