Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Обсуждаем R/O mapping для .Net  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Предлагаю в этой ветки обсудить существующие средства R/O mapping'а для ADO.Net

Что интересует прежде всего:
- интегрированность с UML/Case-средствами (мне особенно интересна поддержка Sybase PD)
- поддержка средства поставщиком (чтобы не прекратили проект на альфе ;))
- Общий уровень развития средства (т.е. насколько глубоко копнули разработчики)
- Поддержка серверов приложений (мне особенно интересны Sybase EAServer и MTS)
- Наличие успешных проектов с использованием данного средства


За образец предлагаю взять CocoBase и JDO - т.е. параметры оценивать относительно этих продуктов, которые, к сожалению, есть только для java (мне особенно интересен CocoBase -)
4 мар 04, 11:41    [563160]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Вот, например, очень интересная статья про ObjectSpaces и вообще перспективы ORM в .net

Today I've posted this as a reply in the Microsoft.public.objectspaces newsgroup. I think it's also blogging material, so that's why I post it here too. You can decide to react here, on your own blog, but also in the microsoft.public.objectspaces newsgroup, available on the msnews.microsoft.com USENET server.

The person who wrote the quote has a valid point. This is the basis for the thought experiment: will Objectspaces and its quality (and limits) limit interest in O/R mapping?


My problem w/ #4 is that there's no sense creating a vendor dependency on a product that wont be around long after ObjectSpaces is released. Let's face it, without a standards-based approach like JDO to back them up non M$ vendors have zilch going for them other than the fact that ObjectSpaces isn't out yet.

If this is true, MS is thus killing businesses by providing an inferior technology (it supports just 1 db) and still can get away with it. An EJB-CMP or JDO equivalent would have been the best choice, so all O/R mapper vendors could target that spec. Now it's indeed an open market which will be dominated by the one who can set the de-facto standard. It's easy to guess which company that will be.

Still, I think that with the limited feature-set of ObjectSpaces (and the fact that it is not yet available), it is not a good thing for O/R mapping for .NET in general: because it will be seen as the de-facto standard and because its limitations are there, a lot of people will/can think O/R mapping is not for them and will stick with Datasets.

The hype around ObjectSpaces is dying too, as it seems. If you look at the MSDN site, every 2 days or so a couple of articles are posted about next-gen technologies like avalon, indigo, whidbey etc, not ObjectSpaces. As if its a 'last minute' tool and not that important. This can (speculation) probably be caused by the fact that there are problems with the implementation or that it simply isn't seen as an important aspect of .NET 2.0, however it is important for O/R mapper vendors out there.

By ignoring the fact that ObjectSpaces will be seen as the de-facto standard and its limited focus/featureset, Microsoft kills more or less the interest in O/R mapping. After all, O/R mapping is a technology that is not yet widely accepted, you see DataSets everywhere; when an article describes data-access it's in the far majority of cases about DataSets, not about O/R mapping.

Now, in that situation, if a developer's first experience with O/R mapping is ObjectSpaces, will he be looking for other tools because of the fact he's interested in the technology? I don't think so: or he's happy with ObjectSpaces, or he's not happy with ObjectSpaces and is dissapointed in O/R mapping and returns to typed DataSets and stored procedures.

It's not hard for me to produce a group of templates for LLBLGen Pro which generates code / xml files compatible with ObjectSpaces code/targeting ObjectSpaces classes, so people can use my O/R mapper tool to create the mappings. ObjectSpaces however is too limited: no Oracle for example. Now, a lot of Oracle databases behind websites power asp-websites and these will (are) be ported to ASP.NET. Developers look at whidbey, and think: "we have two choices: ObjectSpaces or DataSets". ObjectSpaces doesn't work with oracle, so the logical option will be DataSets. Do you think they start with "I want O/R mapping!"? No, they start by looking at how they can ease interaction with the persistent storage. Because ObjectSpaces is seen as the de-facto standard (by then) and because it doesn't work with for example Oracle, the developers will opt for the other de-facto standard: DataSets.

It's a myth to think that the majority of developers start by "I want O/R mapping" and then look for tools and then start coding. They think in: "I want to / have to read/write data into/from a database" and because they are spoiled with the n-tier model for years, they think in "DAL tier" and "BL tier". The DAL has to do the persistence work. They have .NET 2.0, and start looking for options in .NET 2.0 to work with data. ObjectSpaces, DataSets... the works. What to choose? Only if they tried them all and have read that O/R mapping really is great and some tools out there offer solutions for O/R mapping for .NET, they'll start looking for those tools. In all other situations, they'll either stick with ObjectSpaces or if that's a dissapointment, will then try DataSets.

So for O/R mapper vendors, as I see it, it's a choice between a rock and a hard place. If ObjectSpaces is great, interest for O/R mapping will grow, however because ObjectSpaces is great and free and already installed with .NET 2.0, why bother buying another tool? If ObjectSpaces is not that great, interest in O/R mapping will die away ("I looked at it, but I don't understand the hype") for the majority of developers and the reason to buy another tool for O/R mapping purposes is fading away.

I really don't know what to do. O/R mapping really needs a lot of positive air-time in the .NET community to gain interest, otherwise it will die a quiet death and will stay the technology of a few people. I understand the propriety API issues that come with every O/R mapper vendor out there, but because Microsoft has made a fatal error by not offering a great, standard API spec like EJB-CMP or JDO to work with, this will not change.

In the end, the average developer will suffer from this, because the amount of choices for O/R mappers all using the same API is not available. The average developer will also not move to O/R mapping instantly, because it is not an appealing technology because of ObjectSpaces' limitations. (or as the head of DotNed (The Dutch .NET user group) described it (not literally): "It's a very complex technology, only use it if you're really interested.")

For the coming 6 months I've decided to write as much positive things about O/R mapping as I can, to make it interesting for a lot more people so when ObjectSpaces arrives they'll not be dissapointed in O/R mapping because of ObjectSpaces but will know that there are alternatives which do produce what they want.

I hope other O/R mapper vendors will follow that initiative so more and more people will get interested in O/R mapping in general.

(C) к сожалению не знаю кто именно - но то что мужик - зверь это очевидно

PS> странно, что тема никого пока не заинтересовала ;)
6 мар 04, 13:08    [566674]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
привет
PS> странно, что тема никого пока не заинтересовала ;)
а ты не туда ее бросил, надо было в проектирование
а этот форум звездный войн некоторые читают нечасто

Что интересует прежде всего:
- интегрированность с UML/Case-средствами (мне особенно интересна поддержка Sybase PD)

а где там, собственно, средства для маппинга-то?
там получаешь "в лоб" реализацию CRUD для каждого класса...
представь, что у тебя в проекте более 1000 классов, сколько кода породится только для голого CRUD
я бы не стал PD считать средством для маппинга...

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

посмотри внимательно на это

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

- Общий уровень развития средства (т.е. насколько глубоко копнули разработчики)
пока все копнули неглубоко, есть неплохой Constructor - это плагин для VS.Net, но ему еще тоже расти и расти...

- Поддержка серверов приложений (мне особенно интересны Sybase EAServer и MTS)
какая именно поддержка нужна?

- Наличие успешных проектов с использованием данного средства
тут PD пока что, наверное, чемпион
остальные проекты не так давно начались-то

За образец предлагаю взять CocoBase и JDO - т.е. параметры оценивать относительно этих продуктов, которые, к сожалению, есть только для java (мне особенно интересен CocoBase -)
смотри на том же rsdn идет разработка куда как более продвинутого Coco для дотнета
7 мар 04, 11:11    [566886]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
Не видел ни одного средства которое бы позволяло делать маппинг на хп.
Поэтому DAL-слой приходится полностью руками реализовывать.
27 дек 04, 18:21    [1213020]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
В качестве лучшего решения поставленной задачи предлагаю
Versant Open Access .NET.

1) Компания существует более 15 лет.
2) Технология во многих аспектах годами отрабатывалась и на Java (JDO), и на C++ продуктах.
3) Существует аналогичный продукт для JDO (Versant Open Access JDO).
4) Развитие и поддержка гарантированы.
5) Успешные проекты имеются.

В данный момент Open Access .NET существует только в пререлизе (релиз ожидается в начале 2005 года).
Но большинство решений перекочевали в него из FastObjects .NET, который обладает схожей (и даже большей) функциональностью, но помимо O/R отображения (фактически эта функциональность в нем факультативна) включает объектную СУБД.
27 дек 04, 18:46    [1213083]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
Дык маппинг на хп он делает или нет?
Если нет, то и без него решений полно неплохих и бесплатных, кстати.
27 дек 04, 18:49    [1213091]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Роман Дынник
Дык маппинг на хп он делает или нет?


А в каком виде вам представляется такой мэппинг?
И чем это кардинально отличается от средств уже стандартно-доступных в MSVS .NET ?
27 дек 04, 19:08    [1213123]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
А в каком виде вам представляется такой мэппинг?
И чем это кардинально отличается от средств уже стандартно-доступных в MSVS .NET ?

В виде помапить свойства класса на параметры хп для ins,upd,del.
В ADO.NET единственный объект, который позволяет это сделать DataSet - о его недостатках при реализации бизнес-объекта можно почитать здесь.
28 дек 04, 09:35    [1213610]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Роман Дынник
автор
А в каком виде вам представляется такой мэппинг?

В виде помапить свойства класса на параметры хп для ins,upd,del.


Видимо такой подход имеет право на существование. ИМХО, проблема решается очень просто.
Мэппинг класса делается на представление (View), а процедуры подключаются в виде ON INSERt, upd, del триггеров. Значительного геморроя я здесь не вижу.
28 дек 04, 10:02    [1213728]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
Это все не то...
DataSet(хоть типизированный, хоть нет) слишком тяжеловесен, плохо вписывается в ООП.
Поймите, не зря же мелкие замутили ObjectSpace.
28 дек 04, 10:21    [1213813]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
vdimas
т.е. ты не получаешь ср-во для динамического маппинга классов на объекты БД, ты получаешь статический маппинг в коде, сгенеренном этой тулзой.
вот тут не понял. а что мешает этот "динамический" маппинг нарисовать в PD?
vdimas
смотри на том же rsdn идет разработка куда как более продвинутого Coco для дотнета

где именно?
Rsdn.Framework.Data ?

Список продуктов:Object-relational mapping
28 дек 04, 11:41    [1214203]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
вот тут не понял. а что мешает этот "динамический" маппинг нарисовать в PD

во первых в PD маппинга для .NET нет. Там только для java на основе JDO и Coco.
Во вторых этот маппинг генерит "жесткий" код (т.е. в случае изменения нужна перекомпиляция), а хотелось бы настраиваемый через xml-файлы настройки например.
28 дек 04, 11:56    [1214278]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
автор
во первых в PD маппинга для .NET нет. Там только для java на основе JDO и Coco.

Йопт! ну естественно нет.
vdimas спросил "а где там, собственно, средства для маппинга-то?"
то есть даже не .NET а вообще....
а там есть средства для маппинга. да, не для .NET. да, для Cocobase и JDO. и генерирует настройки для них. только судя по всему vdimas это маппингом не считает. может кто-нибудь когда нибудь и нарисует xem файл для какого-нибудь ObjectSpaces. тогда будет и для .NET

Роман Дынник
Во вторых этот маппинг генерит "жесткий" код (т.е. в случае изменения нужна перекомпиляция), а хотелось бы настраиваемый через xml-файлы настройки например.

да?! это кто вам сказал? Вот я вижу что для Cocobase PD генерит как раз xml-файл конфигурации. отображения объектов на таблицы. сгенерировать можно и сами объекты. а можно и вручную написать. это как вам больше нравится.

З.Ы. и чего вы все так перекомпиляции боитесь... не понимаю...
28 дек 04, 12:26    [1214408]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
ЗоринАндрей
автор
для Cocobase PD генерит как раз xml-файл конфигурации

Ну значит не досмотрел, оБшибся :))
Rsdn.Framework.Data пробовал?
Как впечатления?
28 дек 04, 13:10    [1214688]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
автор
и чего вы все так перекомпиляции боитесь... не понимаю

перекомпиляции может и не стоит бояться... если все хорошо по сборкам разложено, но вот отлаживать не удобно в ходе разработки...
28 дек 04, 13:13    [1214707]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
Роман Дынник
Rsdn.Framework.Data пробовал?
нет. и скорее всего не буду. глянул на доку и чувствую что то не то...
один класс с несколькими десятками методов...
да все и не перепробуешь.
я лучше на nHibernate посмотрю.
28 дек 04, 15:35    [1215455]     Ответить | Цитировать Сообщить модератору
 Re: Обсуждаем R/O mapping для .Net  [new]
Роман Дынник
Member

Откуда:
Сообщений: 3324
nHibernate только в альфе по-моему пока. сыровата...
Правда там обещают маппинг на хп релизнуть.
28 дек 04, 15:50    [1215526]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить