Здравствуйте, Cyberax, Вы писали:

C>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало
Можешь ссылку дать или сам рассказать в 2х словах?

Здравствуйте, EvilChild, Вы писали:

C>>Мультикастовость, кстати, в Java обычно тупо реализуют в вызывающем контейнере с помощью множества обработчиков.
EC>А можешь привести минимальный пример реализации мультикастового события? Там контейнер обработчиков вручную ведётся?
Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.

Здравствуйте, Cyberax, Вы писали:

C>Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.
С этим понятно: аналоги += и -=. Хотя всё равно лишняя возня, которую за тебя может компилятор сделать.
Контейнер, где хранятся подписчики сам создаёшь и рулишь им?

Здравствуйте, Cyberax, Вы писали:

C>Я уже привел пример с Hibernate. Почти весь DAL концентрируется в отдельной библиотеке, в результате в основном коде можно не волноваться о мелочах. Статическая проверка тоже в большинстве случаев нормально делается.

Ты привёл пример, использующий строковые константы. Какая нафиг статическая проверка? Или ты думаешь, что достаточно замазать в одном месте и точно такие же ошибки в другом месте не вызовут проблем?

C>Ужжжас, а не пример.
C>Откуда мы берем соединение для работы с Cusomer'ом?

Можно подумать для работы с хибернейт нужно каждый раз по месту читать конфиги и открывать соединения с БД.

C>Что будет при навигации по связям от него?

Зачем мне куда-то нафигировать?

C>Вернется ли нам disconnected dataset?

Для веба можно вообще не возвращать никаких данных, а отмапить датаридер непосредственно в http response. У меня такой фигнёй занимается один контрол, рисующий отчёты. Мегобайты хэтэмээля отлетают со свистом абсолютно не нагружая при этом сервер. А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.

Отчёт, кстати, динамический. Пользователи сами определяют его вид, бродят по нему и дрилдаунят во все стороны. Потом строится SQL и результат рендерится в response. Прошу обратить внимание, никакого хибернейта при этом не используется.

А ещё у меня используется вот такой код в серверных частях приложений, где я не могу использовать вебсервисы по определённым причинам:

private void Map<T>(IEnumerable list)
{
    BLToolkit.Mapping.Map.SourceListToDestinationList(
        new EnumeratorMapper(list.GetEnumerator()),
        new TextDataListMapper(new TextDataWriter(Response.Output, typeof(T))));

    Response.Output.Flush();
}

Тип объекта здесь нужен исключительно для того, чтобы обеспечить маппер метаданными. Если вместо EnumeratorMapper у нас будет DataReaderMapper, то опять же данные из ридера будут не задерживаясь уезжать в сеть. EnumeratorMapper используется лишь по причине того, что данные нужно кешировать.

C>Какой пользователь используется для работы с данными?

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

Здравствуйте, ., Вы писали:

.>Не совсем уж и сахар. Главное — возможность определять классы внутри методов, притом с локальным конекстом. Как такое
.>делается в c#?

В C# замыкания выглядят так, как к ним давно привыкли функциональщики во всём мире. При это никто специально не хакал CLR, чтобы обеспечить возможность захвата контекста.

Здравствуйте, IT, Вы писали:

IT>А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.

Документ как создаёшь? Через XML?

Здравствуйте, Cyberax, Вы писали:

C>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало

Расскажи про хаки.
Единственное упоминание об inner и anonymouse классах — это пара необязательных аттрибутов в классе (исключительно для дебаггера), и методы в Class (isInner() и т.п.) возвращающие результат на основании имени класса (гы).
Ты знаешь что-то ещё?

Здравствуйте, mkizub, Вы писали:

C>>Не совсем, там еще пара хаков в JVM есть для того, чтобы это все работало
M>Расскажи про хаки.
В ru.java было обсуждение (в котором ты, AFAIR, принимал участие ) — поля в проксиках инициализируются раньше вызова суперконструктора, для этого им хак в верификатор пришлось поставить. И еще один подобный хак есть, но я его не могу вспомнить.

Здравствуйте, EvilChild, Вы писали:

IT>>А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.

EC>Документ как создаёшь? Через XML?

Нет. Используется какая-то платная библиотечка. Через XML тоже создавал, но результат был много хуже. Один процессор на сервере стабильно зашкаливал за 100%.

Здравствуйте, EvilChild, Вы писали:

C>>Да. Тупо делаются методы addBlahBlahListener и removeBlahBlahListener. Неэстетично, зато дешево, надежно и практично.
EC>С этим понятно: аналоги += и -=. Хотя всё равно лишняя возня, которую за тебя может компилятор сделать.
EC>Контейнер, где хранятся подписчики сам создаёшь и рулишь им?
Ага. Обычно так и пищут:

Set<SomeListener> listeners=new HashSet<SomeListener>();
void addSomeListener(SomeListener listener)
{
   listeners.add(listener);
}
...

Это просто очень нечасто нужно бывает.

Здравствуйте, IT, Вы писали:

C>>Двухуровневые системы были плохими из-за прямой работы с данными в коде UI.
IT>Ещё раз специально для самых одарённых. Проблемы работы с данными в коде UI нет, так же как и нет проблемы при чтении этих данных, например, из коллекции сериализованных объектов. Проблема в том, что работа ведётся с нетипизированными данными. В этом случае у нас пропадает контроль со стороны компилятора. Постарайся понять эту разницу и не путать причину и следствие.
Я тебе в который (пятый?) раз говорю, что можно для большинства запросов Hibernate сделать контроль типов с помощью плугина к IDE. И это уже сделано. И это уже работает.

Для байндинга так вообще типизированность обычно пофиг — grid'у все равно что отображать, главное чтобы порядок правильный был.

C>>У меня идет прямая работа с бизнес-объектами, а mapping'ом их на базу данных занимается Hibernate. Всякие security и прочее обеспечиваются с помощью interceptor'ов, тоже подключаемых к Hibernate.
IT>В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.
У меня возвращается List<BusinessObject>, который вполне типизирован.

EvilChild wrote:

> .>Главное — возможность определять классы внутри методов, притом с
> локальным конекстом. Как такое
> .>делается в c#?
> Методы можно. Мне кажется этого достаточно, если знаешь когда нет, то
> приведи пример.
Разница есть на уровне детализации. Интерфейс может содержать несколько методов, их удобнее переопределять пачкой,
скажем событие FocusObserver имеет два метода — onFocus/onBlur. Ну и класс может содержать собственное состояние.
Скажем:

...
FocusObserver fo = new FocusObserver()
{
    int howMuch = 0;
    onFocus(){++howMuch;}
    onBlur(){killUser();}
};
control.setObserver(fo);
control.kick();
if(fo.howMuch...)
...

Здравствуйте, ., Вы писали:

.>Разница есть на уровне детализации. Интерфейс может содержать несколько методов, их удобнее переопределять пачкой,
.>скажем событие FocusObserver имеет два метода — onFocus/onBlur. Ну и класс может содержать собственное состояние.
.>Скажем:
.>

.>...
.>FocusObserver fo = new FocusObserver()
.>{
.>    int howMuch = 0;
.>    onFocus(){++howMuch;}
.>    onBlur(){killUser();}
.>};
.>control.setObserver(fo);
.>control.kick();
.>if(fo.howMuch...)
.>...
.>

В таком случае можно и неанонимный приватный класс завести. В чём преимущество анонимности в данном случае?
В C# можно объявить анонимные методы, причём там можно захватывать лексический контекст,
что устраняет необходимость делать эти методы членами одного класса.

Здравствуйте, IT, Вы писали:

IT>Это понятно, но это уже не декларативно Не проще было бы обойтись вообще без ифоф? Если у меня пять таких полей, то нужно будет наприсать 10 строчек такого кода. А можно просто перечислить все пять полей в одной. Опять же повторю. Такой паттерн имеет смысл унифицировать, если он действительно часто повторяется. Ради одного-двух раз париться не стоит.

Я линком никогда не пользовался, но знаю, что он вырос из embedded dsls типа haskelldb. Еще я вижу код Sinclair. Из всего этого я заключаю, что queries в linq являются composable, т.е., попросту говоря, first-class. Таким образом, все (может быть, почти все — точно не проверял) Ваши высказывания на эту тему идут лесом. Привет.

Здравствуйте, IT, Вы писали:

C>>Я уже привел пример с Hibernate. Почти весь DAL концентрируется в отдельной библиотеке, в результате в основном коде можно не волноваться о мелочах. Статическая проверка тоже в большинстве случаев нормально делается.
IT>Ты привёл пример, использующий строковые константы. Какая нафиг статическая проверка? Или ты думаешь, что достаточно замазать в одном месте и точно такие же ошибки в другом месте не вызовут проблем?
ИНСПЕКЦИИ IDE! У меня даже строковые регэкспы инспекциями проверяются.

C>>Ужжжас, а не пример.
C>>Откуда мы берем соединение для работы с Cusomer'ом?
IT>Можно подумать для работы с хибернейт нужно каждый раз по месту читать конфиги и открывать соединения с БД.
Нет. У меня есть четко выраженая сессия, с которой я явно работаю.

C>>Что будет при навигации по связям от него?
IT>Зачем мне куда-то нафигировать?
Просто так...

C>>Вернется ли нам disconnected dataset?
IT>Для веба можно вообще не возвращать никаких данных, а отмапить датаридер непосредственно в http response. У меня такой фигнёй занимается один контрол, рисующий отчёты. Мегобайты хэтэмээля отлетают со свистом абсолютно не нагружая при этом сервер. А вот экспорт в excel, который требует построения определённой структуры данных в памяти уже заметно просаживает сервер как по памяти, так и по CPU.
Это все понятно, тут никаких проблем нет. Используй StatelessSession — у нас она для синхронизации гигабайтовых баз используется.

IT>Отчёт, кстати, динамический. Пользователи сами определяют его вид, бродят по нему и дрилдаунят во все стороны. Потом строится SQL и результат рендерится в response. Прошу обратить внимание, никакого хибернейта при этом не используется.
А у нас точно такое же, но при этом в отчете идет сложная аналитика, которая на SQL просто не реализуется нормально (поиск лучшего расписания, например).

IT>

IT>private void Map<T>(IEnumerable list)
IT>{
IT>    BLToolkit.Mapping.Map.SourceListToDestinationList(
IT>        new EnumeratorMapper(list.GetEnumerator()),
IT>        new TextDataListMapper(new TextDataWriter(Response.Output, typeof(T))));
IT>    Response.Output.Flush();
IT>}
IT>

IT>Тип объекта здесь нужен исключительно для того, чтобы обеспечить маппер метаданными. Если вместо EnumeratorMapper у нас будет DataReaderMapper, то опять же данные из ридера будут не задерживаясь уезжать в сеть. EnumeratorMapper используется лишь по причине того, что данные нужно кешировать.
Это все мелочи, не вижу тут никаких проблем. Для меня многомегабайтные отчеты — далеко не самый интересный частный случай, это все рутина.

Другое дело сложные алгоритмы или, например, система со сложными взаимосвязями (сейчас их задаем с помощью движка правил) — без ORM можно повеситься.

C>>Какой пользователь используется для работы с данными?
IT>Я не знаю как там у вас в хибернейте, но у нас в дотнете пользователя всегда можно вытащить из текущего контекста без всяких проблем.
"Контекст" — это ЗЛО. Мы используем глобальную/thread-local переменную. А если я захочу с двумя источниками данных работать?

Здравствуйте, awson, Вы писали:

A>Я линком никогда не пользовался, но знаю, что он вырос из embedded dsls типа haskelldb. Еще я вижу код Sinclair. Из всего этого я заключаю, что queries в linq являются composable, т.е., попросту говоря, first-class.
Ага, Erik Meijer даже как-то объяснял что ноги у него растут из монад.

EvilChild wrote:

> В таком случае можно и неанонимный приватный класс завести. В чём
> преимущество анонимности в данном случае?
Тем что оно анонимно , т.е. имя не надо придумывать. Если тебе нужно переопределить фокусы у пяти контролов, тебе
придётся придумать имена для каждого именованного класса. И если этот класс используется только в одном блоке, то
неоправданно расширяется область видимости класса.

> В C# можно объявить анонимные методы, причём там можно захватывать
> лексический контекст,
> что устраняет необходимость делать эти методы членами одного класса.
Но со структурной т.з. всё-таки поудобнее, имхо. Контекст изменяемый сразу виден — то что внутри класса. Можно
группировать события, скажем, события от клавиатуры (keyup/down/press), от мыши (mouseup/down/hover) и т.п.

Здравствуйте, Cyberax, Вы писали:

C>Я тебе в который (пятый?) раз говорю, что можно для большинства запросов Hibernate сделать контроль типов с помощью плугина к IDE. И это уже сделано. И это уже работает.

Ты понимаешь какую чушь ты говоришь? А если файл, которые затронули мои изменения не открыт в IDE? Всё, не шмагла?

C>Для байндинга так вообще типизированность обычно пофиг — grid'у все равно что отображать, главное чтобы порядок правильный был.

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

IT>>В твоём примере ты делаешь точно тоже, что делалось 10 лет назад — ты используешь нетипизированную работу с данными.
C>У меня возвращается List<BusinessObject>, который вполне типизирован.

Ты строкой задаёшь запрос, в котором используются строковые имена таблиц и полей. Дальнейшее уже не важно.

Здравствуйте, awson, Вы писали:

A>Я линком никогда не пользовался, но... все (может быть, почти все — точно не проверял) Ваши высказывания на эту тему идут лесом. Привет.

Спасибо, друг! Повеселил!

Здравствуйте, IT, Вы писали:

GZ>>Факты в виде цифр есть?
IT>Вообще-то, это мой вопрос.
Ваще-то я на твой вопрос уже ответил. И IMHO достаточно логично ответил, так что опровергнуть можно только реальными цифрами профайлинга.

IT>pass-through как термин существует вне зависимости от линка. Это объективная реальность, присутствующая в большинтсве правильно спроектированных проектах, в которых логика диктуется UI.
У меня не присутвует. Всегда есть какие-то довески. Что я делаю неправильно?

GZ>>Также, я не особо верю что макросы, как аналогичный функционал, спасут мир и будут концептуально лучше чем LINQ2SQL.
IT>Макросы как альтернативу линку я привёл лишь в качестве примера. Мысль состоит в том, что на макросах можно было бы сделать такой же линк и даже лучше, но ещё вчера.
На сегодня нет ни релиза Nemerle, ни Go Live лицензии линки. Поэтому можно говорить только о завтра.

IT>И ООП и макросы — это иструменты. Сравнивать нужно не их, а результаты их применения. А уж известность подводных камней как преимущество — это вообще здорово. Ты никогда не пробовал решать проблемы, а не коллекционировать их, описывать и классифицировать?
Соберем все грабли и посчитаем шишки? Очень не хотелось бы на коммерч. проектах пользоваться этим советом.

GZ>>>>LINQ2SQL — можно считать заменителем или хелпером для DAL.
IT>>>Ты вообще в курсе для чего нужен DAL?
GZ>>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.
IT>Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция.
Ответ как раз верный. Изоляция — это уже средство.

IT>При этом DAL не решает проблему полностью. С помощью DAL мы загоняем её в дальний угол, где её можно лучше контролировать. Но не более того. Проблема всё ещё существует.

IT>Что делает линк. Линк позволяет работать с БД в терминах основного языка, компилятор которого теперь может на 100% контролировать правильность кода работы с БД ещё в компайлтайм.
Не точно так. Правильность кода на соответсвие метаданным.
IT>Это происходит потому, что линк не оперирует строками, а исключительно строготипизированными метаданными. Кстати, на макросах можно было бы пойти ещё дальше — автоматически синхронизировать эти метаданные с БД во время компайл-тайм.
Уже лучше. Только полностью синхронизировать не удастся. Реляционные метаданные недостаточны. Можно только проверить соответсвие. И это можно сделать вполне внешними средствами.

IT>Так вот, теперь подумай, если проблема, которую раньше решал DAL исчезла, то зачем нужен сам DAL?
IT>>>

IT>>>class UI
IT>>>{
IT>>>  void OnLoad()
IT>>>  {
IT>>>    binder.List = from c in Customer select c;
IT>>>  }
IT>>>}
IT>>>

GZ>>Пример достойный example или простейшего проекта.

IT>О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.
Чудный примитивизм. А если вспомнить что еще есть кластерный транзакционный кэш, то примитив улетучивается.

IT>Я уже показывал выше. Впрочем, вот копипейст:

IT>

IT>grid.Source = from c in customers   
IT>              join o in orders on c equals o.Customer into oo   
IT>              select new { c.CompanyName, OrderCount = oo.Count()
IT>

IT>Идея в том, что структура возращаемая запросом является одноразовой. Используя слои ты вынужден объявлять такие структуры в публичном интерфейсе. Но для публичного интерфейса такие структуры не более чем мусор.
Это не есть то, что я спрашивал. Например, для администратора нужен фильтр один фильтр, а для простого пользователя другой фильтр.

IT>>>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?
GZ>>Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.

IT>И как тебе в этом случае поможет наличие pass-through методов?
GZ>>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,
IT>Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?
В одном раздельном слое? Этот слой называется бизнес-логикой, и он не зависит от UI.

GZ>>а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации.
IT>А после следующей итерации у нас появятся методы, которые вообще никем не используются. И так и будут висеть по жизни рудиментами и атавизмами.
А что, их так сложно поубивать? Если слой тестируемый, то контролировать его легко. Хотя можно иногда оставить рудименты пока компилятор не заругается.

GZ>>В ситуации бардака, стоимость внесения изменений увеличивается.
IT>Если ты бардаком называешь линк, то попробуй представить что нужно сделать для того, чтобы добавить в запрос выше ещё одну колонку CompanyAddress. А теперь представь что нужно сделать для того, чтобы добавить её же в случае с логикой, размазанной по слоям.
Не очень много. Измени поле в entity и где и какие изменения проверяются компилятором. Чаще всего, они инкапсулированы в отдельном компоненте(ежели разработчик дружит с головой). А вот лазить по UI (который чаще сложнее чем все остальное) не очень хочется.

GZ>>Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым.
IT>Что именно ты собираешься тестировать? Соответствие имён полей структур и полей таблиц в БД? Так это за тебя уже сделал компилятор.
Нет. Именно то, что называют чудовишным и непонятным словом бизнес-логика. Действия и возможности которые предоставлены клиентам бизнес-логики.

GZ>>А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.
IT>Это заблуждение. Точнее, нежелание отказываться от старых привычек.
Нет. Может я устарел, но в UI я никогда не буду делать действий не связанных с интерфейсом пользователя. Там своей сложности всегда хватит.