Предлагаю в этой ветки обсудить существующие средства R/O mapping'а для ADO.Net

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


За образец предлагаю взять CocoBase и JDO - т.е. параметры оценивать относительно этих продуктов, которые, к сожалению, есть только для java (мне особенно интересен CocoBase -)

Вот, например, очень интересная статья про 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> странно, что тема никого пока не заинтересовала ;)