[ЖЖ][Flame] .NET, SQL, Collection API

>Почему люди, которые пишут на .NET так радуются такой фичи как запросы на подобие SQL из коллекций? Это и вправду такая killer feature?

На .NET не пишу, но SQL это и на самом деле гораздо лучший способ работать с множествами чем через for(i=0,..., for(i=0,... , for(i=0,... Все эти ООП-аппликейшен сервера по факту суть регрессия к навигационному способу работы с данными.

>Почему люди, которые пишут на .NET так радуются такой фичи

далеко не все.

>Это и вправду такая killer feature?

прикольно, но портит вид/читабельность программы.

> Почему люди, которые пишут на .NET так радуются такой фичи как запросы на подобие SQL из коллекций? Это и вправду такая killer feature?

Люди, которые пишут на Common Lisp, такими фичами несколько десятилетий как пользуются. И, да, это очень удобно. Может и C# допилят до такого удобства, лет через 15.

> прикольно, но портит вид/читабельность программы.

Это как это? Для тебя десяток вложенных for-ов более читабелен?!?

>Это как это? Для тебя десяток вложенных for-ов более читабелен?!?

этим должна заниматься база данных

Раз уж тут заговорили про .Нет, нехочу создавать новую тему. Кто-нибудь использует Mono на работе, т.е. не j4f, а для коммерческого пр-я?

>Люди, которые пишут на Common Lisp, такими фичами несколько десятилетий как пользуются. И, да, это очень удобно. Может и C# допилят до такого удобства, лет через 15.

только вот почему-то: http://www.langpop.com/ :\

>Раз уж тут заговорили про .Нет, нехочу создавать новую тему. Кто-нибудь использует Mono на работе, т.е. не j4f, а для коммерческого пр-я?

да.

> Все эти ООП-аппликейшен сервера по факту суть регрессия к навигационному способу работы с данными.

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

> Кто-нибудь использует Mono на работе, т.е. не j4f, а для коммерческого пр-я?

Я, например. Причём, под Win32, а не только OS X и Linux. Причина - IKVM и managed C# compiler. Таких killer features у оригинального .NET ещё долго не появится.

Я тоже так считаю.

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

> этим должна заниматься база данных

Дурак. Внешняя БД - это очень медленно и труднонастраиваемо. На каждый чих, на каждую внутреннюю структуру данных заводить БД будет только идиот.

> да.

Забыл о специфике Лора :)

> Кто-нибудь из местных использует Mono на работе, т.е. не j4f, а для коммерческого пр-я? Расскажите о впечатлениях, use case и проблемах.

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

Да элементарно, даже обычные кэши с LINQ гораздо проще и нагляднее организуются.

А что из этих кэшей нужно такую сложную выборку делать? Неужто по составному ключу не организовать поиск?

P.S. Может чушь сказал, я не в теме.

ну и ананимусы, сплошное хамло.

>Внешняя БД - это очень медленно и труднонастраиваемо

ну ты понял кто дурак, да?

>На каждый чих, на каждую внутреннюю структуру данных заводить БД будет только идиот.

зачем на каждый чих? или у тебя на каждый чих используется десяток вложенных циклов? соболезную.

> А что из этих кэшей нужно такую сложную выборку делать? Неужто по составному ключу не организовать поиск?

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

Если у тебя все задачи сводятся к плоской таблице с одним ключём, то тебе повезло.

> ну ты понял кто дурак, да?

Да понятно, что ты. Ты же не программист, а тупое ламерьё.

> зачем на каждый чих? или у тебя на каждый чих используется десяток вложенных циклов? соболезную.

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

>> Все эти ООП-аппликейшен сервера по факту суть регрессия к навигационному способу работы с данными.

>http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

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

>Расскажите о впечатлениях, use case и проблемах.

как правило, нетривиальный проект потребует нетривиального подхода. Хочешь писать под mono - надо писать именно на нем, написать под .NET, а потом чтобы работало под mono - либо тривиально либо работать не будет.

Особенной задницей прикручивается ASP.NET, mod_mono - глюкалка, и к ней нужен свой "подход". Наблюдаются постоянные проблемы с кодировками и несовместимостью web.config (сейчас точно не помню, но было летом)

В целом если приложение написано прямыми руками - работает стабильно. Не течет, не греет воздух. Даже на маломощных VPS ведет себя прилично. Используется 1.9.1 (да, кстати, удручает свежесть моно в дистрибутивах, в частности Debian.)

Windows.Forms не использую, если что-то и писалось для себя на WF - работает под mono, но выглядит на рабочем столе как куча говна посреди клумбы (особенно на маке).

> Используется 1.9.1

Глюкавина редкостная. В 2.0.1 до фига ошибок исправили.

> реляционный подход - это все разумное, доброе и вечное

Бгг. Хотя, если считать "реляционным подходом" Третий Манифест, то да. Но так считать нельзя :D

> ООП - это трата времени на написание бесполезных маппингов и их мэйтенанс.

Надеюсь, ты перепутал OOP и ORM от усталости или еще какой-то уважительной причины.

>Да понятно, что ты. Ты же не программист, а тупое ламерьё.
>У тебя все структуры данных простые и примитивные? Поздравляю, ты быдлокодер. А у меня сложная логика, и высокие требования к производительности.

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

>Глюкавина редкостная. В 2.0.1 до фига ошибок исправили.

я в курсе :) просто принцип - "работает - не трогай!" в действии.

В том и дело, что оно вообще не работает. Там фатальные ошибки.

>> ООП - это трата времени на написание бесполезных маппингов и их мэйтенанс.

>Надеюсь, ты перепутал OOP и ORM от усталости или еще какой-то уважительной причины.

Да не совсем так - начинать разработку приложений надо отталкиваясь от стратегии потребления IO и прочих ресурсов а не от объектной структуры. Но всегда делают наоборот, предварительно почитав Эриха Гамму и Ко.

Ребята, не парьтесь, всё равно вы супротив Луговского как начавший вчера материться школьник против грузчика Петровича.

Интересно. Расскажи в двух словах, как можно проектировать приложение отталкиваясь от стратегии потребления ресурса. Мне просто интересно. И, что в твоем понимании "стратегия потребления ресурса"? Это случаем не набор use case?

Ну, вот например, есть поток однотипных записей, поступающих в реальном времени, с time stamp. Приложение должно реагировать на каждое новое поступление (строго n раз в секунду), и при этом может требоваться доступ к значениям за заданные промежутки времени в прошлом. Типичнейшая в финансах задача. Когда подобные задачи лошьё пытается проектировать в объектно-ориентированной религии, получается полный швах.

Напоминает содикса, с его подражанием луговскому.

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

Для начала нормальные запросы написать. И стресс-тесты для бэкэндов выполнить чтобы выяснить как же они под ожидаемой нагрузкой вести себя будут.

Честно говоря, я не понимаю в чем проблема при OOD в приложении такого рода.

Ну да приходит запись, какое-нибудь Entry, ну да, есть какой-нибудь EntryCache, что суть есть мапа timeStamp -> Entry.

Есть EntryListener, который дергается при приходе новой записи. EntryListener знает о EntryCache.

Можешь назвать меня "лошьем", но лучше объясни как ты предлагаешь решать такие задачи. Я просто напросто не сталкивался с таким.

Речь не об этом. Речь о проектировании самого приложения. Я тоже не совсем понял, что человек имел ввиду.

P.S. Ура! Получился NETосрач!

>> Надеюсь, ты перепутал OOP и ORM от усталости или еще какой-то уважительной причины.

> Да не совсем так - начинать разработку приложений надо отталкиваясь от стратегии потребления IO и прочих ресурсов

В огороде бузина... потребление ресурсов-то причем? И как его оценивать без модели приложения?

Хм... а я думал я один его не понял.

>>> Надеюсь, ты перепутал OOP и ORM от усталости или еще какой-то уважительной причины.

>> Да не совсем так - начинать разработку приложений надо отталкиваясь от стратегии потребления IO и прочих ресурсов

>В огороде бузина... потребление ресурсов-то причем? И как его оценивать без модели приложения?

А как делать модель приложения не зная как оно должно потреблять ресурсы?

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

> А как делать модель приложения не зная как оно должно потреблять ресурсы?

Ыыыы.... выzснение, сколько ресурсов будет будет потребляться - одна из задач модели. Аналитическая модель, имитационная; для простых случаев - прикидки на клочке бумаги, для сложных - полнофункциональный прототип.

P.S. вообще-то разговор был о навигационном способе данных vs SQL, тебя всегда так заносит в сторону?

s/способе данных/способе доступа к данным/

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

По факту обязательно кто-нибудь будет передавать 1Гб рекордов через ArrayList в построитель отчетов, и с имея гибкую объектную модель Жавы отрефакторить все это можно будет только переписав все нафиг.

Странно, что кто-то будет такое делать.

Но, при проектировании мы же не говорим о реализации. Поэтому кто это будет - ArrayList или другой объектик, который будет прозрачно тянуть данные из БД мы не знаем. Нам важна структура. Важно что есть построитель отчетов - ReportBuilder, есть какой-нибудь ReportDataRepository или как тебе больше нравится. И ReportBuilder получает этот ReportDataRepository. Ну или как-то так. А что из себя внутри представляет ReportDataRepository - это не дело проектирования.

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

P.S. Я не сторонник чистого RUP, но основные концепции... почему бы и нет.