Здравствуйте, AndrewVK, Вы писали:
AVK>Но взаимодействует с ней на уровне базовых сервисов, почти на уровне драйверов.
Он специфичные фичи использует и оптимизирован на эту ОС.
AVK> Достаточно вспомнить о том что он работал и под НТ 3.5, а ядро с тех пор не сильно изменилось.
Кто тебе такую глупость по 3.5 сказал? Ни в жизнь не запустится. На 4-ке и то если сервиспаки поставить.
DG>>А где я показывал избыточную информацию?
VD>Ты же одним махом все деталзы вынул.
Это ты про то, что из XML-я DataSet только целиком все читает?
DG>>Т.е. ты хочешь серьезно сказать, что SQL умеет возвращать что-то сложнее таблицы?
VD>В таблицы (если с умом) можно все что хочешь заложить.
Угу, а всю информацию можно представить ввиде последовательности ноликов и единичек, а все операции представить через And, Or и Not.
Вопрос, а стоит ли делать, что второе (представлять в виде 0/1), что первое (реляционнить данные)?
DG>>А заворачивать дерево ответа в таблицу — это какой-то такой большой костыль. И самое главное, не понятно зачем это надо, если можно этого не делать.
VD>Дык дерево в таблице как раз хратится очень даже неплохо.
Хранится, то оно неплохо, а вот запрос очень нехороший получается.
Вот представь, что у тебя в базе лежит дерево каталогов и тебе нужно его все вывести на экран в expand-нутом виде (аля explorer).
И как в этой задаче будет выглядить sql-запрос? Ты предлагаешь на каждый уровень формировать новый sql-запрос? Или сделать один запрос, а потом руками по нему бегать?
P.S. Что ты привезался к моему хранению данных в Xml-е? Это просто деталь реализации. С тем же успехом и минимумом переделок, я могу те же данные положить в Sql, задача и проблемы от этого не изменяться.
Здравствуйте, DarkGray, Вы писали:
DG>Вопрос, а стоит ли делать, что второе (представлять в виде 0/1), что первое (реляционнить данные)?
У тебя на кону надежность данных. Вопрос преобразования данных все же решается. А вот надежность...
DG>Вот представь, что у тебя в базе лежит дерево каталогов и тебе нужно его все вывести на экран в expand-нутом виде (аля explorer).
Я такие задачи решал не раз.
DG>И как в этой задаче будет выглядить sql-запрос? Ты предлагаешь на каждый уровень формировать новый sql-запрос? Или сделать один запрос, а потом руками по нему бегать?
Если нужно все дерево за раз на клиента вынут, то это один простой запрос. Выбираешь всю таблицу, а на клиенте ее парсиш и формируешь дерево где нужно.
DG>P.S. Что ты привезался к моему хранению данных в Xml-е? Это просто деталь реализации. С тем же успехом и минимумом переделок, я могу те же данные положить в Sql, задача и проблемы от этого не изменяться.
VD>Если нужно все дерево за раз на клиента вынут, то это один простой запрос. Выбираешь всю таблицу, а на клиенте ее парсиш и формируешь дерево где нужно.
Дык, а может лучше такую таблицу в DataSet вынуть, он как раз парсинг и сделает. Вот тут как раз удобство DataSet-ов и проявится.
Здравствуйте, VladD2, Вы писали:
AVK>>Естественно. ASP.NET ведь называется весь комплекс. Просто для ядра названия нет.
VD>Я тебе о том, что все ASP.NET разрабатывалось ради этих самых веб-формсов и контролов.
Мальчики, не спорьте.
Смотрю я на вас и никак не могу понять, то ли вы прикалываетесь, то ли одно из двух.
Скорее всего AVK говоря о контролах подразумевает дизайнер, а ты наоборот Дизайнер в студии действительно дерьмецо ещё то, именно поэтому я им если и пользуюсь то только для наброска макеты страницы, потом я на него вообще не переключаюсь и делаю всё ручками. Если же говорить о контролах, то тут AVK terribly wrong. Веб-контролы как раз та часть, которая позволит ASP.NET натянуть всех конкурентов по самые помидоры. Не исключено, что как раз сейчас все те самые конкуренты в суматоже пытаются изобразить что-то подобное.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, DarkGray, Вы писали:
DG>Дык, а может лучше такую таблицу в DataSet вынуть, он как раз парсинг и сделает. Вот тут как раз удобство DataSet-ов и проявится.
А нафига? Все равно одну таблицу тянуть на клиента. Однууу! Тут что датасет, что рекордсет...
Здравствуйте VladD2, Вы писали:
AVK>>Их много, этих сторон
VD>Ну а ты о главных. Колись!
Главная жопа ejb — оверхед на преобразованиях. Т.е. никаких групповых апдейтов — все поштучно. Но эта жопа в общем то понятна — из-за чего она и что мы получаем взамен известно.
Еще одна жопа проистекает из жопы джавы — нет боксинга. В результате ручной боксинг/анбоксинг достает конкретно.
Далее — стандарт мало вещей описывает, особенно EJB 1.0. Поэтому с каждым сервером приходится разбираться отдельно.
Еще одна задница — рефлекшен вроде в джаве есть, но вот то что для добавления метода в объект приходится править аж в трех местах, это странно, прям возврат к идеям С++. Почти все команды, с которыми мне доводилось сталкиваться писали свои кодогенераторы, где на основе 1 файла на 1 бизнес-объект генерились все необходимые интерфейсы и деплоймент-дескриптор.
Вот вроде бы все основные задницы на которые я напарывался.
Здравствуйте VladD2, Вы писали:
AVK>>Но взаимодействует с ней на уровне базовых сервисов, почти на уровне драйверов.
VD>Он специфичные фичи использует и оптимизирован на эту ОС.
Да я и не спорю. Я тебе уже говорил — то что он заточен под ОС еще не значит что он очень тесно с ней взаимодействует в процессе работы.
AVK>> Достаточно вспомнить о том что он работал и под НТ 3.5, а ядро с тех пор не сильно изменилось.
VD>Кто тебе такую глупость по 3.5 сказал? Ни в жизнь не запустится. На 4-ке и то если сервиспаки поставить.
Почитай историю создания sql сервера. Он вышел одновременно с первой коммерческой версией NT.
Здравствуйте VladD2, Вы писали:
AVK>>Просто это когда все в одном солюшене и пересобирается автоматом.
VD>Ну это уже совсем просто. Думаю этот глюк они в следующей версии исправят.
Здравствуйте, DarkGray, Вы писали:
DG>Это я видел, вот только не понял, как с этой штукой программным образом взаимодействовать (чтобы данные можно было получать в программе)
Можно и обычными запросами. Например:
CREATE TABLE #t1 (i1 INT, i2 int)
insert into #t1 values(1, 1)
insert into #t1 values(1, 2)
insert into #t1 values(1, 3)
CREATE TABLE #t2(i1 INT, i2 int)
insert into #t2 values(1, 1)
insert into #t2 values(2, 1)
insert into #t2 values(3, 1)
select 1 as Tag, null as Parent, null as [root!1], null as [level1!2!i1], null as [level1!2!i2],
null as [level2!3!i1], null as [level2!3!i2]
union all
select 2 as Tag, 1 as Parent, null as [root!1], #t1.i1 as [level1!2!i1], #t1.i2 as [level1!2!i2],
null as [level2!3!i1], null as [level2!3!i2]
from #t1
union all
select 3 as Tag, 2 as Parent, null as [root!1], null as [level1!2!i1], #t1.i2 as [level1!2!i2],
#t2.i1 as [level2!3!i1], #t2.i2 as [level2!3!i2]
from #t1
join #t2 on #t2.i1=#t1.i2
order by [level1!2!i2], Tag
for xml explicit
Здравствуйте, VladD2, Вы писали:
VD>Ну а всем преимущество?
1) Однородность. Никакой кучи языков. В случае CMP можно даже про SQL забить. Джава и только джава.
2) Изолированность от деталей. Практически весь код бинов это бизнес-логика, средства обеспечения функционирования невелики и могут быть сгенерены автоматически.
3) Больше работы, в отличие от ком+, ложится на сервер. Т.е. тебе остается практически только бизнес-логика и клиент.
4) Все таки в объектной модели, по крайней мере мне, заметно удобнее писать, чем в реляционной.
5) Возможность выбрать сервер приложений от нескольких поставщиков.
Для некоторых серверов возможность менять бизнес-логику без рестарта сервера и редеплоинга приложения.
Думаю этот глюк они в следующей версии исправят.
Если нам не помогут, то мы тоже никого не пощадим.
