> > Now the java world is considering radical ideas like POJO as > > an alternative ;-) > > Seriously: I doubt it. the EJB-CMP specs (especially the latest) > is very solid. You can pinpoint to new technologies all you want but > .NET hasn't an equivalent of that spec anywhere in sight.
Sorry, POJO is Martin Fowler's joke on this point: plain old java object. On EJB-CMP, substantial numbers of users have bailed on the idea. Among best practices for using J2EE, many recommend not using entity beans. My point isn't to discuss the merits of EJB, but to question the assumption that by beginning with a spec and a reference implementation, a good platform will be developed. There are probably more examples of it not working that of successes. JDO is still is an open book, isn't it? How about a c# implementation? > > In the case of OR tools, I don't think there is anywhere near > > enough consensus on how to do it to implement a sane spec, do > > you? > > Why not? I found the EJB-CMP spec nice, sometimes a little > farfetched but overall very good. O/R mapping is pure overhead code, > it's there because an OO paradigm requires translation to a relational > model to work. Object queries, large data stores, having to implement abstract classes, interfaces, skill sets, source of meta-data, many more things are currently all done quite differently by each implementation. EJB-CMP chose a model that hasn't been as widely used as I would imagine Sun had hoped. All things things represent design tradeoffs that are very hard to answer in the general sense. At this point, a product can take a stand, here is how we do it, and then users can choose a product with the tradeoffs least painful to accept. A complete spec by MS at this point would force a set of tradeoffs that may not hit a large enough base of users. > A good spec only defines the core services that have to be > provided and I find EJB-CMP a good example for that. A tough issue will > probably be the object query language, however that too will be a minor > point in the end: there is always something to gripe about: be it not > type safe or be it too verbose or other things. As long as the spec > offers extensibility, it would be great. > What about a smaller set of specs? What would be the least amount of specifications you would deem useful. Actually, an object query language would be one of my first choices, with some relativley simple specs on how to call the query processor, interfaces for the results. Perhaps an implementation that would work on generics. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
