Признаться, термин "топология" не кажется мне применимым в данном случае. [img]images/smiles/icon_smile.gif[/img] Но если не придираться к мелочам и оставить этот термин, то и разбиение на data management tier и business logic tier также можно назвать "топологией" -- всеж таки они крайне редко разделены так четко и однозначно. [img]images/smiles/icon_smile.gif[/img]

Разбиение presentation tier на server layer и user layer удобно именно уже с начальных этапов проектирования. В том числе -- в плане проработки поддержки небраузерных клиентов, браузеров различных версий т.п.

(я все думаю, скоро ли кто-ниюудь скажет: "джентельмены, а это ничего, что я к вам спиной сижу?" [img]images/smiles/icon_biggrin.gif[/img] )

Crazy
(я все думаю, скоро ли кто-ниюудь скажет: "джентельмены, а это ничего, что я к вам спиной сижу?" )
а вот я как раз собирался …. [img]images/smiles/icon_smile.gif[/img]

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

потому что тут на днях у меня спросили, умею ли я нормализировать БД, на что я с круглыми глазами спросил
«- что с ним делать ?!»

- меня обхихикали … потом в шутку рассказали что это такое, и пришлось растолковать как это на самом деле надо делать, причём в результате я чуть ли не пантомимой разьяснял, как именно это надо делать во взятом в пример случае [img]images/smiles/icon_smile.gif[/img]

так что, вы не стесняйтесь [img]images/smiles/icon_smile.gif[/img]

[ 30 Апреля 2002: Исправлено Intelligent ]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Crazy:
<STRONG>Признаться, термин "топология" не кажется мне применимым в данном случае. [img]images/smiles/icon_smile.gif[/img] Но если не придираться к мелочам и оставить этот термин, то и разбиение на data management tier и business logic tier также можно назвать "топологией" -- всеж таки они крайне редко разделены так четко и однозначно. [img]images/smiles/icon_smile.gif[/img]

Разбиение presentation tier на server layer и user layer удобно именно уже с начальных этапов проектирования. В том числе -- в плане проработки поддержки небраузерных клиентов, браузеров различных версий т.п.</STRONG><HR></BLOCKQUOTE>

Топология - это пространственное разделение.
Назвать можно, если они будут разнесены на два сервера, я же предлагаю разделять их, даже если они потом будут жить на одной машине.

Никто и не говорит, что это плохо. Просто это уже ДРУГОЕ дело. Я же предлагаю делить на 3 уровня ради получения значительного увеличения в скорости разработки именно на уровне данных и бизнес логики. И заниматься в итоге разработкой нового кода только для уровня пользователя (тут уже можно и так делить, и сяк делить, и пр.)

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Original Demon:
<STRONG>Топология - это пространственное разделение.</STRONG><HR></BLOCKQUOTE>

Не нравится мне столь грубая трактовка. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote

Цитата:

<STRONG>Назвать можно, если они будут разнесены на два сервера, я же предлагаю разделять их, даже если они потом будут жить на одной машине.</STRONG>

Данные и безнес-логика и так практически всегда обслуживаются двумя разными серверами. Hint: под сервером я понимаю не обязательно отдельностоящую железку. [img]images/smiles/icon_smile.gif[/img]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote

Цитата:

<STRONG>Никто и не говорит, что это плохо. Просто это уже ДРУГОЕ дело. Я же предлагаю делить на 3 уровня ради получения значительного увеличения в скорости разработки именно на уровне данных и бизнес логики.</STRONG>

Собственно, скорость разработки увеличивается не из-за разделения на три уровня как такового. [img]images/smiles/icon_smile.gif[/img] Здесь все и сложнее, и интереснее.

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote

Цитата:

<STRONG>И заниматься в итоге разработкой нового кода только для уровня пользователя (тут уже можно и так делить, и сяк делить, и пр.)</STRONG>

Опа. А вот это я себе плохо представляю. IMHO, идеальный вариант этот как раз наоборот: замороженный presentation tier и оперативные правки в business logic tier.

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Intelligent:
<STRONG>потому что тут на днях у меня спросили, умею ли я нормализировать БД, на что я с круглыми глазами спросил
«- что с ним делать ?!»</STRONG><HR></BLOCKQUOTE>

Ты что ли методом научного тыка учился, а не по мануалам? [img]images/smiles/icon_confused.gif[/img] [img]images/smiles/icon_eek.gif[/img]

Изучение методом научного тыка (и, соответственно, научного вытыка) есть спорт храбрых и искусство сильных. Очень спортивно. [img]images/smiles/icon_smile.gif[/img]

Хоть и не целесообразно... [img]images/smiles/icon_smile.gif[/img]

1) Это дословный перевод.

2) а я говорю как раз про железки

3) естественно не из-за разделения (я видимо плохо выражаю свои мысли, потому что писать лень), а из-за накопления большого объема повторно используемого кода. я имею в виду не скорость разработки текущего проекта, а скорость разработки последующих.

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

1) Я не о переводе, а об уместности термина. [img]images/smiles/icon_smile.gif[/img]

2) А смысл?

Original Demon

неее … не тыком [img]images/smiles/icon_smile.gif[/img]
в школе учили. школа с компьютерным уклоном. я каааак раз в израиль переехал. языка толком не знал, поэтому терминов не запомнил, но смысл понял [img]images/smiles/icon_smile.gif[/img]
а потом доработал и допонял сам. в генах видать тоже было [img]images/smiles/icon_smile.gif[/img]

Crazy, это жизнь веб-программиста, от этогу никуда не уйти, поэтому ООП в вебе ограничено по применению. И надо очень аккуратно подходить к его использованию. А по поводу тормозов СОМ технологии это данные статьи. Сейчас уже не вспомню линку на оригинал. [img]images/smiles/icon_sad.gif[/img] Дело в тормозах интерфейса СОМ-объектов, это аналогично случаю ODBC и ADO, например.

[ 30 Апреля 2002: Исправлено Long ]

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Crazy:
<STRONG>Признаться, книг его я не читал, а потому позволю себе задать вопрос здесь: разве граф в данном случае сам по себе не является одним из представлений алгоритма?

[ 30 Апреля 2002: Исправлено Crazy ]</STRONG><HR></BLOCKQUOTE>

Является, в этом и есть вся идея.

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Crazy:
<STRONG>Я, кажется, понимаю. [img]images/smiles/icon_smile.gif[/img] Речь о том, что кроме скомпилированные -- и, вероятно, быстрых -- объектов COM в проекте будет также связующая среда на интерпретируемом языке, которая "коммутирует" эти объекты. Ради этой связующей среды мы тащим за собой транслятор и имеем потери в скорости.</STRONG><HR></BLOCKQUOTE>

На www.citforum.ru есть хорошая статья "25 способов оптимизации … ASP чего-то там".

И самое главное. Мне кажется, стоит ориентироваться в первую очередь на скорость и качество _разработки_, а потом уже на производительность продукта.

<BLOCKQUOTE><font size="1" face="Verdana, Tahoma, sans-serif">quote:</font><HR>Автор Сообщения Long:
<STRONG>Crazy, это жизнь веб-программиста, от этогу никуда не уйти, поэтому ООП в вебе ограничено по применению. </STRONG><HR></BLOCKQUOTE>

Используйте трехуровневую модель. Падение производительности окупит скорость разработки.

Ну так как, ты уже занялся проектированием или по-прежнему пытаешься сразу перескочить к реализации? [img]images/smiles/icon_smile.gif[/img]