Цитата(Domestic @ 12.4.2005, 20:15)

Поэому я могу написать Java приложение, для использования которого нужнa аутентификация, причем оно не поменяется, если я сменю Виндовс аутентификацию на Керберос.

Ну с этим и в дотНете все в порядке

Цитата(Domestic @ 12.4.2005, 20:15)

Согласен, но JDBC вообще изначально не зависит ни от какого провайдера.

Вероятно, тут используется более высокий уровень абстракции. Но реализация ADO.NET дает возможность использовать навороты того же SQL Server'а, а не только то подмножество, которое общее для всех.

Цитата

Вероятно, тут используется более высокий уровень абстракции. Но реализация ADO.NET дает возможность использовать навороты того же SQL Server'а, а не только то подмножество, которое общее для всех.

Тоже верно, приложение можно оптимизировать под конкретную БД. Зато при переходе на другую БД возникнут проблемы. Для энтерпрайз приложений на разных ОС вещь не такая уж редкая.

Цитата(Domestic @ 12.4.2005, 20:25)

Зато при переходе на другую БД возникнут проблемы.

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

По сути, да

Да, раз уж заговорили о базах данных, хочется спросить: а есть ли среди стандартных классов JAVA (в том же JDBC) что-то хоть отдалённо похожее на DataSet, DataTable, DataRow и DataRelation ? ИМХО, самые удобные средства для detached-работы с базой данных из всех существующих. Плюс, типизированные датасеты, которые генерируются на основании XML-схемы.

JDBC построена на интерфейсе ResultSet и его сабинтерфейсах: CachedRowSet, FilteredRowSet, JdbcRowSet, JoinRowSet, RowSet, SyncResolver, WebRowSet. Реально модель довольно близка к ADO.NET; АДО в этом смысле более "наворочен", хотя JDBC может делать все то же, что и АДО, за исключением релейшншипов.
Кстати, здесь сравнивать сложно, т.к.языки идут своими путями. В Java широко используется Object-Relational Mapping, фреймворки типа Hibernate, JDO. Грубо говоря, можно набор объектов сохранять в БД, причем учитываются такие вещи как наследование (- вот и релейшншипы).
Enterprise Java Beans в некотором смысле ложат АДО.НЕТ одним левым мизинцем, поскольку там вообще программисту никакой БД логики писать не надо - один файл конфигурации, и то в простых случах он займет меньше, чем твой пост. Но EJB ограничены серьезными приложениями, конечно, для простых штук типа складского учета они никак не пойдут.

Цитата(Domestic @ 13.4.2005, 07:30)

Кстати, здесь сравнивать сложно, т.к.языки идут своими путями. В Java широко используется Object-Relational Mapping, фреймворки типа Hibernate, JDO. Грубо говоря, можно набор объектов сохранять в БД, причем учитываются такие вещи как наследование (- вот и релейшншипы).

ORM - это, другими словами, persistence, так? Microsoft предложат свой вариант такого решения в новом продукте Microsoft Business Framework.

Датасеты - незаменимая вещь при работе с табличными данными, будь то информация полученная из БД, или сформированная в рантайме, полученная от веб-сервиса, зачитанная из XML-файла. Кстати, рульная весч: можно взять XML-файл, прочитать его в датасет, и работать с ним как с таблицей БД !!! Поработав, сохранить обратно в файл, поток, http-стрим и т.п.

А если к тому же не полениться и сформировать XML-схему, тогда можно сформировать типизированный датасет, который на порядок удобнее использовать, добавляется возможность проверки корректности структуры данных по заранее сформированным ограничениям (unique key, foreign key, constraint).

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

Взято отсюда. Кто хочет прокомментировать?

Цитата

Сравнение скорости выполнения кода, генерируемого компиляторами C#, Java, VC6, Intel C++, Delphi. Из статьи "Кто сегодня самый шустрый?" Владислав Чистяков Вызов метода объекта (Mehod call)   PIII 800 AMD 1400 в секундах C# (.Net) 2.51 2.16 Java3 8.90 4.20 VC 61 13.89 0 / 5.78 Intel C++1 0.00 0 / 6.32 Delphi 17.58 6.50 VB 62 493.97 204.00 Intel C++ compiler в режиме максимальной оптимизации (/O3 /QaxK или /O3 /QaxM) интерпретировал пустые или содержащие мало кода функции как inline-функции. В результате этого метод Test и его вызовы были полностью соптимизированы, то есть выброшены из программы и заменены на конечный результат. Надо признать, что если в VC-варианте реализацию методов оставить в теле класса (даже без пометки их как inline) VC начинает делать то же самое (так как таким образом объявленные методы считаются inline по умолчанию). Но качество оптимизации у VC оказалось несколько лучше, и он смог больше кода привести к статическим расчетам. В VC есть также и отдельная опция (/Ob2), заставляющая интерпретировать все (по выбору компилятора) вызовы как inline. Ее установка тоже приводит к тому, что этот тест полностью оптимизируется в статическое вычисление. Однако для чистоты эксперимента мы приводим время, которое требуется для вызова метода. На практике есть смысл включать эту опцию, поскольку объем кода при этом увеличивается не так радикально, а производительность может вырасти значительно. VB 6 не может создавать классов в полном понимании ООП. Вместо этого он создает COM-объекты. Вызов метода COM-объекта медленней, чем fastcall, применяемый в других языках, но даже это не может оправдать таких "зверских" накладных расходов. VB-программистам можно посоветовать побыстрее перейти на VB.Net, а пока этого не произошло, избегать частых вызовов функций (особенно из отдельных классов) и реализовывать критичные к скорости алгоритмы на C++ (запаковывая их в методы COM-объектов и DLL-библиотек). Для оптимизации теста в Java к классу был применен модификатор final. По умолчанию все методы в Java являются виртуальными. Причем, в отличие от C++ и C#, Java от Sun не пытается вычислить, что метод можно вызывать без виртуальной таблицы. Это приводит к замедлению работы. Методы, помеченные как final, становятся не виртуальными. Мне кажется, идеология C++ (принятая в C# и Delphi) более практична, но это сугубо личное мнение. К сожалению (несмотря на вкусы), final приводит к некоторым нежелательным последствиям. Так, метод, помеченный этим модификатором, не может быть "перебит" в классе-наследнике, а если помечен класс, то от него вообще нельзя порождать потомков. Конечно, можно забыть про final, но как показывают наши испытания, если закомментировать final в описании класса CTest1, скорость вызова метода падает с 4.13 до 14.47, т.е. почти в три раза. Что же поделаешь - расплата за универсальность. Надо заметить, что остальные языки этого обзора по умолчанию создают обычные (не виртуальные) методы. Чтобы сделать метод виртуальным, необходимо пометить его специальным ключевым словом (обычно virtual). Исключением является VB 6. Он вообще не поддерживает наследования, и, как следствие, виртуальных методов. Однако, по иронии судьбы, так как классы VB 6 являются COM-объектами, вызовы все равно делаются через виртуальную таблицу (необходимую для реализации COM-интерфейса). Вызов виртуального метода объекта (virtual mehod call)   PIII 800 AMD 1400 в секундах VC 61 15.10 5.8 / 6.49 Intel C++ 15.08 6.50 Delphi 21.35 7.01 C# (.Net) 15.66 7.22 Java3 29.15 14.48 VB 62  204.00 Первый результат VC - это результат, полученный при установленной опции, позволяющей компилятору автоматически делать inline-подстановки функций. У VB 6 нет понятия наследования, а значит, нет и виртуальных методов. Однако, как уже говорилось, все методы объектов в VB являются методами COM-интерфейса, а значит пользуются техникой виртуальных таблиц. Т.е. любой метод в VB является виртуальным. Однако, повторюсь, таких тормозов это не объясняет. Лидер нашего первого теста оказался в аутсайдерах в этом тесте. Но не это больше всего огорчает, а огорчает тот факт, что в Java все методы по умолчанию являются виртуальными. На практике это может привести к тому, что Java-приложение окажется медленнее, чем приложения на других языках, и виной тому будет не слабость JIT-компилятора, а просто невнимательность или незнание программиста. Мне кажется не очень правильным перекладывать вопросы производительности на программиста. Ему ведь и так достанется. Но многие Ява-программисты считают по-другому. Так, что вам решать хорошо это или плохо. Доступ к членам класса   PIII 800 AMD 1400 в секундах C# (.Net) 3.99 3.54 Java 7.55 4.85 VC 61 8.84 1.44 / 5.06 Intel C++ 8.80 5.04 Delphi 8.79 4.34 VB 6 118.69 76.53 Первая цифра в тесте VC была получена с включенной опцией "inline-подстановки (раскрытия) функций в любом подходящем случае". Quick Sort (быстрая сортировка)   PIII 800 AMD 1400 в секундах C# (.Net)2 16.73 9.50 / 9.17 Java 24.49 12.50 VC 61 16.61 8.58/ 8.70 Intel C++ 17.63 9.20 Delphi3 16.77 13.59 / 9.60 VB 6 27.01 14.07 Первый результат VC - это результат, полученный при установленной опции позволяющей компилятору автоматически делать inline-подстановки функций. Тест C# был сделан в двух видах - нормальном и "unsafe". Как вы наверно уже догадались, первая цифра - это время в нормальном, а вторая в unsafe-режиме. В нормальном режиме компилятор C# вставляет проверки выхода за границы массива. Отключить такие проверки невозможно, но C# поддерживает unsafe-режим. В этом режиме C# превращается в старый добрый C, позволяя пользоваться указателями. Причем C# имеет конструкцию fixed позволяющую превратить в указатель любой тип C#. При этом в следующем выражении (в одном или в блоке) можно безопасно пользоваться указателем. Вам гарантируется, что сборщик мусора не переместит или освободит память, занятую объектом. После выхода из области действия конструкции fixed указатель становится не действительным, а памятью снова начинает управлять сборщик мусора. Именно этим мы и воспользовались чтобы выяснить на, что способен C#, если программист не боится сложностей и готов на все. В Delphi runtime-проверки выхода за пределы массива и переполнения можно включать или отключать в свойствах проекта. Первое число в таблице - результат с отключенными runtime-проверками, а вторая - с включенными. Если же проверки включить, Delphi начинает делить последнее место с VB 6, проигрывая всем остальным участникам, выполняя этот тест за 13.59 на AMD1400. Хочется сделать еще одно замечание. Мы наступили на забавные, но потенциально очень неприятные грабли. Дело в том, что все современные языки умеют передавать параметры методов как по значению, так и по ссылке. В Delphi для этого используется ключевое слово var. Его необходимо указывать перед параметрами. Все это понятно, но Delphi оказалась единственным компилятором требующим указания модификатора передачи параметра по ссылке для массивов. Оказалось, что Delphi с упорством, достойным лучшего применения, запихивает массив в стек. Думаю, не надо разъяснять, как такая "забота о программисте" отражается на производительности. Но производительность страдает при относительно небольших размерах массивов, в нашем же случае один из массивов имел размер немногим менее ста мегабайт... Получив сообщение об ошибке, мы попробовали трассировать программу под отладчиком, но не тут то было. Пару раз Delphi попросту зависло, еще пару выдало загадочное сообщение. Да и сама ситуация сбивала с толку. Ну, да ладно... Через пару минут тупого разглядывания кода мы поняли, в чем проблема, и устранили ее. Мы понимаем, что сами виноваты, но надо было слышать те слова, которыми мы вспоминали в эти минуты Borland и все компьютеры вместе взятые. Пузырьковая сортировка   PIII 800 AMD 1400 в секундах C# (.Net)2 8.16 6.20 / 5.29 Java 20.63 10.37 VC 63 7.20 5.02 Intel C++3 7.23 4.85 Delphi1 9.53 12.31 / 5.33 VB 61 14.48 21.76 / 8.46 Цифра, приведенная перед результатами тестов Delphi и VB 6 - это время выполнения этого теста с включенной проверкой выхода за границы массивов. Она приведена не для того, чтобы как-то унизить эти средства разработки, а чтобы вы могли оценить качество реализации алгоритма проверки выхода за границы массива в Java и C# (в остальных языках такие проверки не реализованы). Заметьте, время Java, языка, который мы считаем интерпретируемым, оказалось вдвое меньшим, чем у VB 6, и на 20% меньшим, чем у Delphi, которая без этих проверок показала результат близкий к лучшему. C# вообще был вне конкуренции в этой области. 6.2 - это результат, достойный компилятора, не выполняющих никаких runtime-проверок. Но, похоже, это результат не предел. Господа из Microsoft уже поговаривали о верификации кода. Правда, эти разговоры были связаны с безопасностью, но кто мешает вместо выполнения runtime-проверок заняться интеллектуальной деятельностью? Конечно, из-за того, что не вся информация доступна во время компиляции, нельзя заменить все runtime-проверки на статический анализ, но можно же вынести проверки из тел циклов и рекурсивных функций. Как и в прошлом тесте, в этом приводятся результаты работы теста C# в обычном и "unsafe" режиме. Выигрыш составил примерно 10%. Оптимист скажет: есть поле для маневра и ручной оптимизации. Пессимист: можно было бы и пограмотней проверки вставлять. Но как бы то ни было, C# занял первое место в подпольном тесте на лучшую организацию runtime-проверок. Однако в варианте с runtime-проверками C# проиграл лидеру почти 30%. Так что Microsoft есть над чем работать. Ведь тест в unsafe-режиме показал, что разрыв (в 10%) есть и без runtime-проверок. Разрыв между VC и Intel C++ был настолько мал, что на разных платформах они заняли разные места. Делая скидку на неточность вычислений можно даже сказать, что они поделили первое место. Подсчет p (целочисленные вычисления)   PIII 800 AMD 1400 в секундах C# (.Net) 10.35 6.90 Java 10.99 7.56 VC 6 10.76 7.17 Intel C++ 10.08 6.84 Delphi 10.34 6.80 VB 6 20.49 8.74 Tree sort   PIII 800 AMD 1400 в секундах C# (.Net)5 33.66 23.60 Java4 22.91 16.20 VC 61 14.75 11.85 Intel C++1 14.67 12.31 Delphi2 13.96 11.40 VB 63    При повторном тесте время составило около 35 секунд (что на VC 6, что на Intel C++) - это при тестировании на AMD, на PIII 800 повторный тест занял 39.34 секунды. При этом компиляция производилась с многопоточной версией MFC, а стало быть, и с блокировками при выделении и освобождении памяти. После перекомпиляции проекта с однопоточной версией MFC повторное выполнение не приводило к заметному снижению быстродействия. Замедление при повторных тестах вызвано неоптимальной работой стандартных (Win 32 API) функций работы с хипом (HeapAlloce/HeapFree) в W2k. По большому счету, ни VC, ни Intel C++ к этому отношения не имеют. Но тестовое приложение писалось с использованием библиотеки MFC, которая в release-версии пользуется функциями HeapAlloce/HeapFree. Мы попытались создать отдельный хип, заменив методы new и delete. Но это ничего не дало. Единственное, что повлияло - это пересоздание (уничтожение и последующее создание) хипа перед каждым тестом. При этом время выполнение теста было одинаковым. К сожалению, в реальных приложениях такие фокусы проходят с трудом. Но если скорость выделения памяти (а именно она в основном влияет на скорость создания объектов в нашем тесте) критична для вашего приложения, и в вашем приложении используется многопоточная библиотека, можно обратиться к библиотекам сторонних разработчиков. Например, к библиотеке выпускаемой компанией MicroQuill (www.microquill.com). Судя по рекламе, они не только используют более быстрые алгоритмы, но и приводят к хорошему масштабированию на мультипроцессорных системах. Можно также попытаться создать свою реализацию (вот только не факт, что она окажется более качественной, чем аналог от Microsoft), попытаться найти бесплатную реализацию или плюнуть, ведь подобного экстрима не так-то просто добиться в реальной жизни. Надо отметить, что производительность тестов C++ может резко подняться, если Microsoft перепишет функции управления хипом в будущих версиях Windows. Проводя эксперименты, мы выявили некоторую информацию, которая может показаться вам интересной. Реальное время создания дерева заняло 10 секунд (в тесте на PIII 800). Т.е. 4 секунды производится освобождение занятой памяти. Освобождение заняло почти половину (!) времени теста, и это при нефрагментированной памяти. При втором проходе результаты были вообще плачевны. Мы не будем их приводить, так как не уделили этой проблеме должного внимания. Delphi стала победителем и этого теста. Но это не главное, в конце концов она не намного опередила своих соперников. Главное, что время теста Delphi почти не увеличилось (!) при повторном проходе! Это говорит, что функции работы с хипом в Delphi действительно хороши. И это без дополнительных библиотек и хитростей. Мы провели препарирование победителя и выявили, что в Delphi полностью переписана работа с хипом. Для больших кусков памяти используется прямая работа с VirtualAlloc (и т.п.), а для небольших блоков памяти создана хитрая структура, группирующая блоки одинакового размера и хранящая их в отдельных буферах. Чтобы серьезно разобраться в том, как в Delphi сделаны функции работы с хипом, потребовалось бы слишком много времени, да и задача эта в наши планы не входила. Тем же, кто хочет знать больше, мы советуем обратиться к исходникам, прилагающимся к Delphi, благо их никто не скрывает. Правда, они (как и большая, системная часть кода VCL) не документированы, так что придется ползти на животе. VB 6, как известно, об объектной ориентации вообще слышал мало. Он не поддерживает наследования, а стало быть, наш тест в полной мере выполнить не может. Не будем домысливать, но шансы на серьезные позиции в этом тесте у него не велики. Java отказалась работать с настройками по умолчанию еще при попытке загрузки 100 МБ массива, выдав сообщение о нехватке памяти (и это, как вы помните, при 384 МБ RAM на одной машине, и 512 - на другой). Чтобы заставить ее поверить, что на машине есть еще оперативная память, нам пришлось применить не шибко стандартную опцию -Xmx256m, тем самым объясняя Java, что на машине есть минимум 256 MB RAM, которые она может использовать. Но для данного теста и этого параметра оказалось недостаточно, и пришлось уверить Java в том, что на машине есть 400 МБ (с помощью опции -Xmx400m), после чего она-таки уверовала, что памяти достаточно и смогла выполнить тест. Остальные подопытные не сомневались в количестве оперативной памяти, но расходовали ее более экономно. Наличие такой опции само по себе не проблема, но то, что ее значение по умолчанию не завис от объема оперативной памяти - это плохо. В новые языки/платформы типа C# и Java встроены модные ныне "сборщики мусора". Это программные сущности, призванные радикально ускорить выделение и освобождение небольших кусков памяти (так присущих ООЯ). Нам говорят примерно следующее: GC (сокращение от Garbage Collector) вообще не занимается лишним освобождением памяти. Вернее, он пытается отложить этот неприятный (для него) момент на как можно более поздний срок. Т.е. пока есть свободная память, ее будут занимать, занимать и занимать, а когда память иссякнет, или когда процессор будет менее загружен, начнется процесс сборки мусора. При этом процессе выявляются и освобождаются неиспользуемые области памяти. Используемые области памяти при этом могут передвигаться, наподобие того, как это происходило в Windows 3x. Красота, да и только! Но, что характерно, чем громче реклама, тем менее стоящая идея (или реализация) за ней скрывается. Увы, в случае с GC это правило работает стопроцентно. Ни C#, ни Java не показали достойного результата. Java была лучше в абсолютном первенстве на чемпионате для калек, показав относительно неплохой результат в 16.2 секунд, но при повторном тесте ее производительность могла изменяться в пределах от одной до пятидесяти (50!) секунд. C# показал хотя и стабильный, но самый низкий результат. Правда, C# (а вместе с ним и вся платформа .Net) пока еще находится в beta-версии, и к release-версии все может измениться. Но пока C# - явный аутсайдер. Хочется предостеречь читателей от попытки делать далеко идущие выводи о GC как таковом и их реализациях в Java/.Net. Данный тест далек от реальных условий и не учитывает некоторых тонкостей (типа различных стратегий GС в Java). String-тест   PIII 800 AMD 1400 в секундах C# (.Net) 7.18 3.38 Java 7.55 3.48 VC 6 15.40 6.08 Intel C++ 14.40 3.39 Delphi 22.28 10.97 VB 6 22.30 10.20 Float-Тест   PIII 800 AMD 1400 в секундах C# (.Net) 39.28 12.24 Java 39.05 12.98 VC 6 39.08 12.26 Intel C++ 0.50 0.29 Delphi 39.35 12.24 VB 6 46.54 15.13 Выводы. ...Можно с уверенностью сказать, что C#/VC.Net и Java - это языки/среды, на которых можно создавать высокопроизводительные приложения. Особенно это касается C#. Интересно, что p-код (из которого состоят выполняемые файлы) обоих сред не только не является недостатком, но и наоборот является преимуществом. Дело в том, что оптимизация производится в момент компиляции, причем под конкретный процессор. Это значит, что все среды, создающие машинный код, могут производить оптимизацию только под один известный им процессор (В VC использовалась оптимизация под Pentium Pro, в Intel C++ под PIII, Delphi не сообщила о своих планах по этому поводу). P-код ориентированные платформы (VC.Net и Java) производят компиляцию в машинный код перед запуском или во время исполнения программы (.Net-приложения могут быть прекомпилированы в момент инсталяции или вручную с помощью утилиты ngen (что, собственно, мы и делали). Но не следует забывать, что в .Net p-код никогда не выполняется в режиме интерпретации, т.е. даже без применения ngen будет производится компиляция, но при каждом запуске исполняемого модуля.). Естественно, в этот момент уже известен процессор и другие характеристики системы, на которой должен будет выполняться компилируемый код. Теоретически это должно давать p-код ориентированным платформам фору, за счет использования более производительных инструкций. Но как показывают наши тесты, пока это только теория. По всей видимости дело в том, что большинство кода попросту не использует новые высоко производительные команды процессоров, а во вторых они пока не избавились от "детских болезней" присущих всем новым продуктам. Однако потенциал велик. C# отчетливо доказал, что язык нового поколения способен создавать код не только сравнимый по скорости с лучшими образцами старого мира, но и превосходящий их! А так как Microsoft и Sun готовы вкладывать поистине невообразимые деньги в развитие своих детищ, то у этих языков/платформ большое будущее. Так что, похоже, появившиеся в СМИ заявления о том, что Microsoft планирует заморозить развитие Win32 API, языка C++ и COM, и перевести всё и вся на новую технологию .Net, являются правдой. Но как показало наше тестирование, для нас с вами это не представляет угрозы.

Цитата(arilou @ 13.4.2005, 15:46)

В результате этого метод Test и его вызовы были полностью соптимизированы,

Уже частный случай.
Остальное вроде прилично, но как-то перестал верить я этим тестам. Кто платит, тот заказывает музыку...
Интересно также было бы узнать, во-первых, какие версии были протестированы, а главное - на какой платформе?

Цитата(mr @ 13.4.2005, 11:08)

Датасеты - незаменимая вещь при работе с табличными данными,

Это спорное утверждение

С точки зрения сложного бизнес-приложения, программисту намного удобнее оперировать понятиями предметной области, нежели записями из таблицы (например, объектами Клиент, вместо отдельных записей из таблицы Клиенты). Как известно, существует 2 основных подхода к работе с реляционными данными в приложении.

1) Table Mapping. Его суть заключается в том, что для каждой таблицы в БД, в программе используется один класс. Данный подход всегда пропагандировался MS начиная с DAO. Были resultsets, recordsets. Теперь - datasets, причем последние реализуют disconnected-модель работы с БД.

2) Domain Model. Смысл в том, что для каждого типа записи в таблицах БД создается отдельный класс, т.е. программа оперирует объектами этого типа как отдельными сущностями, т.е. понятиями своей предметной области. Реализация данного подхода называется O/R mapping. Для .NET уже существуют ORM-проекты. Даже я свой написал

Оба подхода имеют преимущества и недостатки. Table Mapping хорошо вписывается там, где не много таблиц, и операции над реляционными данными сводятся к CRUD. В .NET типизированные датасеты позволяют реализовать проверку соответствия типов на этапе компиляции (что есть хорошо). К сожалению, типизированные датасеты не очень хорошо подходят на роль базовых классов для бизнес-сущностей, потому что содержать очень много автосгенерированного кода, усложняющего понимание.

Domain Model хорошо подходит, когда необходимо программировать бизнес-процессы, которые оперируют несколькими сущностями. Например, проводка финансовой транзакции, как минимум, затронет такие сущности, как Счет, Клиент, Приход, Расход и т.д. В данном сценарии программисту намного проще реализовать бизнес-операцию, если он будет брать из репозитория экземпляры нужных ему сущностей, модифицировать их, и commit'ить изменения в хранилище. Хорошие ORM пакеты выполнят всё, что связано с БД, сами (откроют-закроют транзакцию, обеспечат блокировку и т.д.).

К сожалению, пока .NET не содержит встроенных средств для поддержки ORM. Говорят, будет Object Spaces. Сейчас уже есть сторонние разработки - DeKlarit, OpenAccess.NET, NHibernate, и т.д.

Цитата(arilou @ 13.4.2005, 16:04)

NHibernate

Даже не буду спрашивать, откуда появилось

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

Цитата(Lamer @ 13.4.2005, 16:26)

Вообще, я слышал больше негативных отзывов о подобных механизмах отображения, чем позитивных

А какие именно приводились "негативные" отзывы?

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

Цитата

Взято отсюда. Кто хочет прокомментировать?

По-моему, это 2002 год, то есть, Java 1.5 еще не было Потом непонятно, что сравнивали, скажем, банальная вещь : был ли включн флаг -server при запуске jvm? Вообще же результаты говоря сами за себя: пиште на том, что нравится

Цитата(arilou @ 13.4.2005, 16:04)

Цитата Датасеты - незаменимая вещь при работе с табличными данными Это спорное утверждение С точки зрения сложного бизнес-приложения, программисту намного удобнее оперировать понятиями предметной области, нежели записями из таблицы (например, объектами Клиент, вместо отдельных записей из таблицы Клиенты). Как известно, существует 2 основных подхода к работе с реляционными данными в приложении.

Я подчеркнул бы слова "табличные данные". Ведь речь не идёт об объектах, а именно о упорядоченном наборе данных, организованном в виде структуры определённого вида, со средствами для доступа, управления и анализа данных. Датасет - это более низкий уровень, чем объект, маппированный, на БД. Но в то же время, с датасетом легко работать и точно знаешь, что происходит в любой момент времени, в то время как при ORM-подходе приходится терпеть "накладные расходы" на содержание объектов в транзакциях, на создание и отслеживание связей между объектами, поддержку маппирования (съедающую иногда больше процессорного времени, чем выполнение запроса к БД)...

Я считаю, что датасеты .NET (aka ADO) - полезная вещь, и при умелом обращении могут заменить маппированные на БД объекты.