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

← →
Курдль © (2006-10-23 15:34) [0]

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

← →
Ученик чародея. (2006-10-23 15:41) [1]

Получила, но на машине должна быть установлена Java нужно версии. Подходит в основном для корпоративщиков.

← →
Курдль © (2006-10-23 15:49) [2]

Я наивно ожидал от ASP.NET, что при ее распространении браузеры будут пользовать .NET Framework (как ява VM). А клиент от сервера будет получать готовую сборку, благо что она на порядок меньше exe-шника той же функциональности (тем самым решая извечную проблему развертывания и обновления). Однако ничего подобного не произошло - тот же тупизм, что на Перле или ПХП :(

← →
Ученик чародея. (2006-10-23 16:11) [3]

> Курдль © (23.10.06 15:49) [2]
>Однако
> ничего подобного не произошло - тот же тупизм, что на Перле
> или ПХП :(

Щас придет Kerk и тебя порвет "как Бобик грелка".

← →
Курдль © (2006-10-23 16:15) [4]

> Ученик чародея. (23.10.06 16:11) [3]
> Щас придет Kerk и тебя порвет "как Бобик грелка".

Ну пусть порвет :(
Заодно хоть объяснит, как следовать принципам ООП при создании страниц и при этом не сдохнуть от геморроя "обмен с сервером при каждом чихе"...

← →
clickmaker © (2006-10-23 16:21) [5]

> не сдохнуть от геморроя "обмен с сервером при каждом чихе"...

http://www.codenet.ru/webmast/js/ajax/

← →
Ученик чародея. (2006-10-23 16:22) [6]

> Курдль © (23.10.06 16:15) [4]
>
>
> > Ученик чародея. (23.10.06 16:11) [3]
> > Щас придет Kerk и тебя порвет "как Бобик грелка".
>
> Ну пусть порвет :(
> Заодно хоть объяснит, как следовать принципам ООП при создании
> страниц и при этом не сдохнуть от геморроя "обмен с сервером
> при каждом чихе"...

AJAX? http://ru.wikipedia.org/wiki/AJAX

← →
Курдль © (2006-10-23 16:27) [7]

> AJAX

Это только попытка сгладить указанный мною выше геморрой.
Требуется от нормального ООП возвращаться к каменному топору типа JavaScript.

← →
Real © (2006-10-23 16:30) [8]

Ну так и диманический вэб существует не так уж и долго... Считай что это еще эра "каменного века", отсюда и топоры соответствующие

← →
Palladin © (2006-10-23 16:45) [9]

AJAX? :) ЭТО называют технологией оказывается? :) шутить изволите...

← →
ZeroDivide © (2006-10-23 16:57) [10]

диманический вэб

%)

← →
Gero © (2006-10-23 17:04) [11]

> [9] Palladin © (23.10.06 16:45)

А почему нет?

← →
roottim © (2006-10-23 17:26) [12]

Мне понравилась библиотечка от яху
http://developer.yahoo.com/javascript/
Очень приличненький такой топорик каменного века :)

← →
Palladin © (2006-10-23 17:51) [13]

> А почему нет?

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

← →
Ломброзо © (2006-10-23 18:07) [14]

>Palladin © (23.10.06 16:45) [9]
Во-во. HTML must сдохнуть.

> Курдль © (23.10.06 15:34)
Лично я сейчас пробую связку .NET Remoting через HTTP + ClickOnce. То бишь: в веб-приложении крутится .NET Remoting сервис, и там же рядышком лежат дистрибутивы "толстых клиентов", которые пользователь запускает прямо с интранет-сайта. В приниципе можно хостить .NET-контролы прямо в IE аля апплет, но похоже, что эта технология потихонечку утратила перспективу.

← →
_dimka © (2006-10-23 18:13) [15]

я вот не могу понять при чем тут аякс и ООП?? какая разница как вы будете это делать, AJAX - єто всего лиш асинхронная загрузка страницы, а как это сделаете - это уже другие проблемы...

← →
Palladin © (2006-10-23 18:16) [16]

> я вот не могу понять при чем тут аякс и ООП??

а не нужно понимать, бо это не так абсолютно...

← →
Курдль © (2006-10-23 18:18) [17]

> Ломброзо © (23.10.06 18:07) [14]

Давай по-понятиям.

> NET Remoting сервис

Это сервис приложений, реализованный с применением .NET Remoting и
настроенный для работы с толстыми клиентами по заявленному протоколу?
Дальше что? Клиент через браузер инициирует загрузку на свой домен сборки с, собственно, клиентсткой частью и запускает ее в штатном режиме под .NET Framework?

> В приниципе можно хостить .NET-контролы прямо в IE аля апплет,
> но похоже, что эта технология потихонечку утратила перспективу.

А вот об этом где можно подробнее почитать?

Я уж давно набил руку на трехзвенке с .NET Remoting. Думал, что так же изящно можно сработать с ASP.NET.
Но не тут-то было :(

← →
McSimm © (2006-10-23 18:19) [18]

> потому что сделав наследник от TStringList"а - мощней, с
> бинарным поиском и множеством вспомогательных методов я
> не смогу назвать это технологией, смогу лишь назвать надстройкой
> и импрувметом, но никак не технологией...

Правильно. Зато это можно смело назвать демагогией :)

Ajax - именно технология, причем есть большое количество разных средств и способов ее реализации.

← →
Курдль © (2006-10-23 18:27) [19]

> _dimka © (23.10.06 18:13) [15]
> я вот не могу понять при чем тут аякс и ООП?? какая разница
> как вы будете это делать, AJAX - єто всего лиш асинхронная
> загрузка страницы, а как это сделаете - это уже другие проблемы.

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

← →
Ломброзо © (2006-10-23 18:28) [20]

Курдль © (23.10.06 18:18) [17]

Это сервис приложений, реализованный с применением .NET Remoting и
настроенный для работы с толстыми клиентами по заявленному протоколу?
Дальше что? Клиент через браузер инициирует загрузку на свой домен сборки с, собственно, клиентсткой частью и запускает ее в штатном режиме под .NET Framework?

Оно самое.

>А вот об этом где можно подробнее почитать?
в MSDN буквально пара статей по этому поводу. Смысл в том, что контрол прописывается в коде HTML в виде
<object id="Panel1" classid="System.Windows.Forms.dll#Panel">

</object>

← →
Palladin © (2006-10-23 18:33) [21]

> McSimm © (23.10.06 18:19) [18]

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

а в чем суть AJAX?... в сокращении траффика на пути донесения до клиента информации... в динамическом формировании контета... так?
"берем то что необходимо", вот ее суть...

ну так, извините меня, это давно уже придумано... и причем уж не автором идеологии, применительно к interweb-сервисам... это не технология, это отображение сущности сетевого программирования вообще... стремление "сетевиков" оптимизировать работу приложения... но технологией назвать очень трудно... назвать можно именно "переносом идеологии/технологии"... но никак не само технология...

← →
Ученик чародея © (2006-10-23 19:54) [22]

> Ломброзо © (23.10.06 18:07) [14]
>
> >Palladin © (23.10.06 16:45) [9]
> Во-во. HTML must сдохнуть.
>
> > Курдль © (23.10.06 15:34)
> Лично я сейчас пробую связку .NET Remoting через HTTP +
> ClickOnce. То бишь: в веб-приложении крутится .NET Remoting
> сервис, и там же рядышком лежат дистрибутивы "толстых клиентов",
> которые пользователь запускает прямо с интранет-сайта.
> В приниципе можно хостить .NET-контролы прямо в IE аля апплет,
> но похоже, что эта технология потихонечку утратила перспективу.

Нуууу если так уж смотреть, то при заходе на сайт ставить в систему ActiveX и затем работать через него. И с апдейтами никих проблем не будет.

← →
Ученик чародея. (2006-10-23 19:59) [23]

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

А ну так тебе тогда прямо в Java. Только клиент должен поставить JRE последней версии. Для создания приложений удобно, для обычного web-сайта нет.

← →
Petr V.Abramov (2006-10-23 23:48) [24]

> Курдль © (23.10.06 18:18) [17]
я бочком присоединяюсь к [1], и попробую переформулировать: какие безгеморройные технологии трехзвеники есть? Под геморроем имеем в виду следующее:

1. необходимость наличия на клиенте библиотек (ActiveX, JИницаторов и т.д, никому на не нужного, особенно администратору сети)

2. прокачка по сети больше байт, чем при "толстом" клиенте. ИМХО, на гоняние в тхт виде скриптов + форматирования + собственно данных трафика идет больше, чем на гоняние только данных.

← →
Petr V.Abramov (2006-10-23 23:49) [25]

Petr V.Abramov (23.10.06 23:48) [24] +
к [0], конечно :)

← →
Ломброзо © (2006-10-24 00:48) [26]

Petr V.Abramov (23.10.06 23:48) [24]

Если мы рассматриваем только интранет с инфраструктурой в виде Active Directory, то я не вижу никаких преимуществ веб перед толстым клиентом, за исключением одного - простоты деплоя. Но. На данный момент мне известны как минимум четыре технологии, снимающие проблему push-распространения обновлений и патчей на клиентские машины:
- Политики AD
- WMI
- Microsoft System Management Server
- Click Once

← →
Petr V.Abramov (2006-10-24 01:03) [27]

> Ломброзо © (24.10.06 00:48) [26]
> Если мы рассматриваем только интранет с инфраструктурой в виде Active Directory, ....
то в профиле msi раскатываем, и никто ниче даже не заметит
все остальное не знаю, к сожалению либо счастью
> Если мы рассматриваем только интранет с инфраструктурой в виде Active Directory,
а если не только, то с параметрами IE в 2003 ПО УМОЛЧАНИЮ зайти на deploy-сайт будет (не знаю как правильно по-медицински, но что-то с функционированием анального отверствия связанное, причем по его изначальному(!:) предназначению )
А в Висте, ИМХО, еще хуще будет :)

← →
ИА (2006-10-24 01:09) [28]

> А вот об этом где можно подробнее почитать?
>

Не стоит оно того, товарищ правильно говорит. Геморроя особенно с security будет столько что наплачешься поддерживать и разбираться что где у кого и почему не работает.

← →
McSimm © (2006-10-24 10:15) [29]

Надо будет себе в визитку пропечатать "узкий специалист по атавизмам" :)

Скажите, а что ж вы цепляетесь за браузеро-то ? :)
Он предназначен-то все же для отображения того-самого html.

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

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

> McSimm © (24.10.06 10:15) [29]
> Надо будет себе в визитку пропечатать "узкий специалист
> по атавизмам" :)

Напрасно иронизируете! :)
Надеюсь, что в ближайшем будущем отпадет надобность в т.н. вэб-программистах и бд-программистах. А все к тому и идет.

> Скажите, а что ж вы цепляетесь за браузеро-то ? :)
> Он предназначен-то все же для отображения того-самого html.

В случае с Java applet-servlet браузер работает именно так, как бы я хотел.
Почему эта технология не победила на всем рынке тонких клиентов?
Надеюсь именно Вы мне объясните, как узкий (но от того не менее уважаемый) специалист!

> Сеть доступна не только браузеру, вот и гоняйте по ней данные
> в чистом виде между своей программой и своим сервером в
> любом удобном виде, какие проблемы ?

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

← →
Danilka © (2006-10-24 10:47) [31]

[26] Ломброзо © (24.10.06 00:48)
> На данный момент мне известны как минимум четыре технологии,
> снимающие проблему push-распространения обновлений и патчей
> на клиентские машины

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

← →
Курдль © (2006-10-24 10:52) [32]

> Danilka © (24.10.06 10:47) [31]
> На моей предыдущей работе таких громких слов видимо не знали,
> поэтому сделали по-простецки:
> бинарники и все что нужно выкладывается на cvs.
> у всех пользователей ярлык не на приложение, а на батник,
> который проверяет актуальность версий файлов, закачивает,
> ежели что-то устарело, с сервера cvs и запускает приложение.

А если пользователи размещены на всей 1/6 суши? Опасаюсь, что CVS не проканает.

← →
Ломброзо © (2006-10-24 10:53) [33]

Danilka © (24.10.06 10:47) [31]

...и все пользователи у нас как минимум Advanced Userы, поэтому батник легко пишет в системные директории и реестр, регистрирует COM-библиотеки и т.п. :)

← →
Danilka © (2006-10-24 11:00) [34]

[32] Курдль © (24.10.06 10:52)
[33] Ломброзо © (24.10.06 10:53)
Ну, там все проще, все пользователи в одной локалке, хоть и в разных концах города. А система такая, что ничего регистрировать ненада, а в реестр писать только в куррент_узер. :)

← →
vuk © (2006-10-24 11:49) [35]

to Курдль © (24.10.06 10:45) [30]:
>А все к тому и идет.
С чего вдруг? В БД вруг все станет оптимально само по себе? Работа с данным через ХП станет вдруг неэффективной? Или что?

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

> vuk © (24.10.06 11:49) [35]
> С чего вдруг? В БД вруг все станет оптимально само по себе?
> Работа с данным через ХП станет вдруг неэффективной? Или что?

Да просто само понятие ХП отпадет за ненадобностью! Как вы не поймете, что пока что нам приходится бороться с проблемами производительности АС?
Мы надеемся, что стремление к унификации разработки рано или поздно победят! Думаю, что ООБД сменят РСУБД в ближайшее время.

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

> Да просто само понятие ХП отпадет за ненадобностью

Вах! А зачем ему отпадать ?

← →
vuk © (2006-10-24 12:06) [38]

to Курдль © (24.10.06 12:00) [36]:
>Да просто само понятие ХП отпадет за ненадобностью!
Ну это если только весь средний слой переедет в БД. В результате будут по сути те же ХП, только объектные.

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

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

> Игорь Шевченко © (24.10.06 12:05) [37]
> > Да просто само понятие ХП отпадет за ненадобностью
> Вах! А зачем ему отпадать ?

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

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

> vuk © (24.10.06 12:06) [38]
> >Думаю, что ООБД сменят РСУБД в ближайшее время.
> Да только вот где они, эти ООБД?

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

← →
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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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-проектировании. Найти похожие ветки