18 Comments

• Kevin Babcock 04 Mar 2010
  Wow, GREAT news! I'm looking forward to the new designer!
• Henrik 04 Mar 2010
  Fantastic news... respect to the team. I am really looking forward to this.
• steve 04 Mar 2010
  More than any other Q1 release, I WANT THIS
• Alex 04 Mar 2010
  I have been waiting for this for sooo long. This is fantasic news. Looks like we can finally build domain objects, build database and then map them.
• Sörnt 05 Mar 2010
  Can we create different views of the same model?
  I would like to have "specialized" views for only a part/s of my total domain model.
  
  In other respects it looks great!
• OpenAccess ORM Team 05 Mar 2010
  Hello Sörnt,
  
  This will not be available for version 1. Can you provide more detais how/why you need a view for a sub-domain? I general  domains should be kept small with the minimal definition. The 'best practice' here is maybe to devise further the domain into smaller ones (if possible) and have different modellers for every and each of them.
  Example: If we go and integrate O/R and WCF for example, this will not go into the same domain - it will require multiple language designers
  
  
• Sörnt 05 Mar 2010
  Hi there,
  
  we have a bigger Domain model with +100 Entities. If I have only one view to that model I guess I loose the focus to my current sub problem. So I would prefere to have an option to create another view and add some of the entities. It is simple a matter of "divide and conquer" it makes it easier to handle.
  
  Another thing: Is the model view "merge-able" with for example with sub version?
  
• Alex Alfonso 08 Mar 2010
  It's Very good .
• Jean Cuteaux 09 Mar 2010
  1) It looks like a wrong approach:
  
  You write: "Mapping Details Editor – It will let you specify the class and association mappings required for the runtime. The tool will also allow you to configure class inheritance and stored procedures for CUD operations for the classes updates."
  
  Stored procedures!!! Come on, what's the use of having an orm if you are back into the old fashion 'procedural' like coding with stored procedures. It is like you have an object model of your database that takes care of all the type safety you want to have, and then at the last segment of your coding journey, you mess up all the effort and the reason of having an ORM by writing 'unsafe' stored procedures.
  
  Stored procedures should be at best exceptional, actually I don't even use them in very complex scenarios, but here u suggest they should be written "for CUD operations for the classes updates". Why have an ORM if you end up write the data access layer in your stored procedures?
  
  2) Your DSL designer is also only good for small and medium size databases, with only not so many tables or not so many fields. Like Linq on which your designer seems to have been inspired by, as soon as we start dealing with very large data stores, the rendering of the designer is extremely slow and cumbersome.
  
  The ORM is good for getting people to discover what 'an' ORM can do, but some things in it are looking wrong:
  
  - Its far from sticking enough to an OO approach
  - Too much code needs still to be written before you actually do anything with the data
  - Too much SQL like syntax when we should be in an OO realm, same weaknesses as Linq or Entity Framework
  - When I access something i don't want to have to write all the time all your dataaccess layer non-sense:
  
  IObjectScope scope = ObjectScopeProvider.Getblabla
  IQuery.... q = the query....
  Setting querytype like forward only....
  IQueryResult = q.Execute();
  
  (this is like 4 lines of none sense and i am still not dealing with the actual objects just a little bit better than using ADO.net)
  
  How about just having something like
  {Let's assume we have a Person Object and Person Table in our database}
     
      PersonColletion AllPersonsJohn = Person.AllEx(Person.Members.Name == "John");
  
  That's one line only, all the dataaccess layer is not needed because you should just set it ONCE in some configuration file or area, since 99% of your code will use the same method, and for the rare cases where you need something different, then some simple methods should be there to implement those access differences.
  
  Anyway precisely because most of the ORM actually on the market are schizophrenic between datalayer Query language and OO programming, I have to use my own ORM framework.
  
• The OpenAccess Team 09 Mar 2010
  Hi Jean,
  
  We will try to answer briefly your questions
  
  Stored Procedures
  As you mentioned already stored procedures are only the other option: by default OA prepares and generates dynamic  sql. We don’t require stored procedures for that, but we have the mechanism to provide support for them. As simple as that.
  
  DSL designer
  Exactly the point – the visual designer is aimed at easy tasks done in an easy way – we do not argue that the concept of such designer will cover the ‘expert-level’ tasks and/or settings (actually for that you can do all the mapping manually in an XML file or via CLR attributes).
  
  "The ORM is good for getting people to discover what 'an' ORM can do, but some things in it are looking wrong…"
  
  We Are in the process of developing a fluent API. While this feature set will not make it probably in the Q1 release, we will have it in the next service pack and provide a human-readable way of mapping things. I guess that is something very similar to your ideas?
  
  
  
  
• Sörnt 09 Mar 2010
  - At brown field projects you have to deal with stored procedures. Sometimes the customers force you to use there db access specifications.
  
  - Stored procedures are the fastes way to access data (pre analyzed, pre compiled)
  
  But I really hope that the stored procedure usage is optional.
  
  As I wrote before: If there is only one view/page is available for your whole entity model than that is not optimal for an entrprise level ORM tool
• Sörnt 09 Mar 2010
  *ups* The OpenAccess Team was faster...
• Vincent 12 Mar 2010
  I installed OA 2010, but I can't see designer. can you tell me how to open designer?
• Daniel 14 Mar 2010
  I too installed OA 2010 demo, and can't see the designer.
• The OpenAccess Team 15 Mar 2010
  Hi guys,
  
  We updated the Q1 distributable accordingly, so if you download all of the noted glitches should be fixed.
  
  We apologize for the inconvenience.
• Neil 15 Apr 2010
  Still can't see the designer in vs2010 RTM downloaded 2010_1_312 that was labeled as the first Q1 2010 release and date from account 2010_1_310. It does offer the option to add a domain model when enabling openaccess but does nothing. Also trying to add new item contains no template for the Telerik domain model.
• Teddy 14 May 2010
  When the Service pack will be released for Q1 2010? As far as I know Q1 2010 has some troubles working under VS 2010 and I'm expecting this to be fixed.
• OpenAccess ORM Team 14 May 2010
  Indeed, the visual designer in the currently available version of Telerik OpenAccess ORM does not support VS2010. We are aware that this is important and are working hard to implement it.
  We are planning to release a version that includes support for VS2010 next week.