ADO.NET v2.0: ObjectSpaces Delivers an O/R Mapper

12 Comments

• ::ObjectSpaces is one of the most exciting
  
  ::parts of .NET v2.0 to me.
  
  
  
  Really? Sorry to hear, because I am bored to death by an O/R mapper that is far behind the industry average for O/R Mappers :-(
  
  
  
  Nice that MS finally gets a grip on OO, too, but sad that ObjectSpaces just lacks everything beesides basic mapping.
  

• Hey Thomas:
  
  
  
  Here's your chance to now publicly state what exactly is missing. I'm not the O/R mapping expert, so I'm honestly not real sure. I like your EntityBroker, but I also like ObjectSpaces, and it will automatically be there on my servers when .NET v2.0 is installed, which is a huge plus! So, what exactly are we missing in ObjectSpaces, and is some of that expected in the Beta possibly?
  

• I actually write a whitepaper about his right now.
  
  
  
  Missing mostly:
  
  * Databinding (n, the ObjectDataSource does NOT cut it - details following in the white paper). This CAN possibly be handled, though.
  
  * Caching, especally in a cross transaction system. No plans from MS to get more intelligent there.
  
  * "Enterprise readiness". Read this, for example, as "Remoting integration". Now, this may not be releavnt for ASP.NET (it is IMHO - we write a CMS where the client uses Winforms and connects back to the server for editing). And some people may say you can remote your objects. Yes, but this SUCKS. And I mean this as verbatim. Handlign events is bad, as is performance. BOTH are things we currently handle with the EntityBroker.
  
  * A service object model, though this is related to remoting.
  
  * Multiple databases. Last time I looked at it, ObjectSpaces was SQL Server only. Maybe I missed something here, though.
  
  * Extensibility. THe ability to dynamically extend the object schema for non-trivial applications. We work on this, by allowing subclasses (inherited from the busines object) to replace them (we call this substitution). This allows some third party using your object model to extend it.
  
  * Extensibility, as in "supporting type inheritance, driven by the database" AND "extend this dyhanically when the ObjectSpace is created". SOme people with the EntityBroker still ask us why we keep the attributes around and dont use a XML file like OS. Simple. We compile the schema from the attribute when the server is created. Gives us flexibility. In general, ObjectSpaces seems not to be ready for modular applications.
  
  * Security Model. ANother issue we handle right now - re-integrating property and method seucrity into the system.
  
  * COM+ integration. IF you need COM+,, wouldn't it be nice if it would just integrate.
  
  * Database Schema Creation. So you deliver a progrm built with ObjectSpaces. Why the heck do you still ahve to deliver the database creation file? e handle this at the moment by adding the database schema information (like indicces) into the compiled dll's and provide a tool that then generates the database. Provider independant (Access, SQL Server - as you wish at deployment time). Scheduled for readyiness in two weeks.
  
  
  
  Now, to the plusses:
  
  
  
  ::it will automatically be there on my servers
  
  ::when .NET v2.0 is installed
  
  
  
  I have a hint for you: the MS Datagrid, is too. Still, we hardly use it. Copying another dll with the application is a non-issue.
  
  
  
  I see ObjectSpaces really as the "MS Datagrid" of O/R mapping right now. VERY basic, VERY limited for everything a little more demanding.
  

• I always love the sound of "oh, hmm.. that's indeed a lot of work" when people discover that with a system of 100+ tables it is suddenly not 'handy' anymore to type in long lists of xml mappings :)
  
  
  
  Though I think Object spaces will be ok when it is released, however I fear it will suffer from the same lack of vision the designers of the dataset had: it's not generic enough: do you want a server-style object broker or adapter style objects, or objects which deal with persistence themselves (3 different patterns, there are way more to define)? How are multiple databases handled? Can I plug in Oracle's superior .NET provider ODP.NET?
  
  
  
  It really depends on the power MS will give the designer for Object spaces. I doubt the design will change anymore.
  

• About the code, you use Northwind, LLBLGen Pro's demo also uses northwind :) So let's compare some code :)
  
  
  
  Object spaces:
  
  Category category = (Category)mapper.GetObject(typeof(Category), "ID=" + this.ID.ToString());
  
  
  
  LLBLGen Pro:
  
  CategoryEntity category = new CategoryEntity(this.ID);
  
  
  
  This is a nice one: OS most likely has to fetch the object from the database. That's a read action which is not necessary. Here we go:
  
  Object spaces:
  
  category = (Category)mapper.GetObject(typeof(Category), "ID=" + this.ID.ToString());
  
  mapper.StartTracking(category, InitialState.Unchanged);
  
  if (this.CategoryID.Text == "0") {
  
  mapper.MarkForDeletion(category);
  
  }
  
  
  
  // ..
  
  category.Name = this.CategoryName.Text;
  
  category.Description = this.CategoryDescription.Text;
  
  mapper.PersistChanges(category);
  
  
  
  LLBLGen Pro: (using the power of its dynamic query engine, which simply executes an update on the server, no read of data first)
  
  CategoryEntity category = new CategoryEntity(); // empty object
  
  category.CategoryID = this.ID;
  
  category.IsNew = false;
  
  category.Description = this.CategoryDescription.Text;
  
  category.Save();
  
  
  
  And a last one, and I doubt Object Spaces should be used this way (the ObjectSpace should be kept in process, or not?)
  
  Object Spaces:
  
  ObjectSpace mapper = new ObjectSpace (Mapping, connection);
  
  ObjectSet objects = mapper.GetObjectSet(typeof(Category), "");
  
  
  
  LLBLGen Pro:
  
  CategoryCollection categories = new CategoryCollection();
  
  categories.GetMulti(null);
  
  
  
  Now, if I can cook up code that is this simple, MS must be able to do it even better, not? :)
  

• Yea, good point, Frans :-)
  
  
  
  With the EntityBroker 2004 we also have the ObjectSpaces API, but we have a reason: we allow the objejcts to live on a remote server, and this - well - requires a factory approach.
  
  
  
  Sadly, between an easy to use appraoch (as LLGBRN Pro) and the feature richness of the EntityBroker 2004 (both avaialble NOW - not in a year with .NET 2.0), I stll think MS has basically killed the market. Noone can compare with a company that just puts the costs down into some area it does not care. long term (and I mean a year from now), noone is going to use any of our products, despite the ease of use.
  

• Excellent comments guys. I still need to test LLBLGen Pro myself. It looks great, and I know EntityBroker is great. I actually did a demo of EntityBroker that ran flawlessly against both MS SQL and Access, and that's been a while so Thomas has added many more features since then. BTW, the ObjectSpaces documentation seems to imply that MS SQL is a short-term limitation, but I never could get this confirmed as the case from anyone.
  

• Ouch Thomas. I doubt that. I would guess your biggest competition is Sysiphus, Norpheme, or something else that's free. I liked Norpheme, even though it was a long way from EntityBroker, and Sysiphus is provider-agnostic already, as well as being open-source. Surely there's a small but viable market for more than MS, but the problem is there a quite a few entries in that field already -- and I've only named the ones I have used or know enough about to think they are deserving.
  

• Well, Paul, thank heaven the EntityBroker is just what it is because we NEED it, not for sales primarily. We work on some stuff that would simply not be pssible with stuff like ObjectSpaces.
  
  
  
  Regarding Norpheme and Sysiphus - well, let me say they were competitors for 2003. For 2004 wejust dust them (all the features I listed as missing in my post above are handlable with Eb 2004 - you should see our remoting solution in action, with NEARLY the same speed as a local object, thanks to extensive local caching).
  
  
  
  But fact is: Microsoft has closed a door here.
  

• Paul: OS is part of .NET 2.0. So when they fix the single db thing, they have to update .NET. This requires a service pack. It won't be there for 6 months I think. With the announcements by IBM and Oracle to support .NET in full strength, this is a major blow for OS.
  
  
  
  The current crop of open source products all follow the same thing: add attributes, and it will be fine. This is not working for projects with 50 or 100 tables or more (and that's common). Not only do you have to write the classes by hand, you also have to type in the mappings by hand.
  
  
  
  When open source tools will get designers that create good mappings and in a fraction of the time, it will be worth it to look at them. Until then, the tools are not really a solution to the real problem: having to type code you can also generate.
  

• Thomas: about the cashflow, same here. We use it to make the company run break even (and even better than that) and we can build projects for clients in the rest of the time.
  
  
  
  Companies who solely rely on one software product like an O/R mapper will get a tough year. Not because competitors get better and a lot cheaper but also because MS ships a tool that will appeal to their target base at first (which will cause a dip in sales)
  

• BTW, here are what classes Foo, Bar, and Blah look like. Notice that they don't extend some tool-provided base class, nor do they have any persistence code in them. References are lazily loaded or fetched with referencing class as desired. Use of standard Java collections is supported.
  
  
  
  public class Foo {
  
  
  
  private String blazz;
  
  private Bar bar;
  
  
  
  public Foo(String blazz) {
  
  setBlazz(blazz);
  
  }
  
  
  
  // no-arg constructor required; can be private if desired
  
  private Foo() {}
  
  
  
  public String getBlazz() { return blazz; }
  
  public void setBlazz(String blazz) { this.blazz = blazz; }
  
  
  
  public Bar getBar() { return bar; }
  
  public void setBar(Bar bar) { this.bar = bar; }
  
  }
  
  
  
  
  
  public class Bar {
  
  
  
  private List blahs;
  
  
  
  public Bar() {
  
  blahs = new java.util.ArrayList();
  
  }
  
  
  
  public void addBlah(Blah blah) { blahs.add(blah); }
  
  public void removeBlah(Blah blah) { blahs.remove(blah); }
  
  }
  
  
  
  public class Blah {
  
  // ...
  
  }
  
  
  
  --matthew