Search   

Friday, February 10, 2012

Support » Support Forum

Register  Login

 Menu  
 
    

 Welcome!  
 


Welcome to the NDO support forum!

kreis.gif Please register/login at the site if you want to post a thread. We sometimes copy support mails of common interest to the forum. They appear with anonymous sender.
kreis.gif Please post your messages in English language if possible. You can do your posts also in German, we will translate your post and our answer so that all users of the forum can read your posts.
kreis.gif The forum software requires that javascript is enabled.
kreis.gif Please do not insert licence information or licence keys in forum posts.
kreis.gif If you know a good answer to a post of another user, feel free to reply!
kreis.gif The forum is monitored. We reserve the right to remove posts we consider not to be useful for other forum users.

   Print   

      
 NDO Support Forum  
 
SearchForum Home
  NDO-Forum postings in english please, if possible.  Developing with NDO  Comparison with...
 Comparison with Wilson O/R Mapper
 
 5/15/2006 5:57:07 PM
anonymous
20 posts


Comparison with Wilson O/R Mapper
 Modified By admin  on 5/23/2006 5:10:21 PM)

Hello, currently I use the Wilson O/R Mapper. With it
- you have to log by yourself if objects are changed in memory and need to be saved,
- you have to check by hand the correct persisting sequence so you do not run into FK constraint problems,
- in conjunction with a query you sometimes load a bunch of similair records in different objects although they have the same primary key.

Does NDO provide a better implementation in these areas?

 5/15/2006 6:03:06 PM
Mirko
109 posts
5th


Re: Comparison with Wilson O/R Mapper
 Modified By Mirko  on 5/15/2006 6:09:09 PM)
First, I have to say, that the Wilson O/R Mapper follows a different approach, so that both products are actually not comparable to each other. Your question shows, that you are working on tasks, for which NDO seems to be the better tool to cope with. NDO automatically detects object changes, you just have to call pm.Save() to store all changes. There is no logging necessary. NDO also takes care of the storage sequence, because it always knows which table holds the foreign key. But I must admit that even NDO fails in this area in certain scenarios. Suggest you have to store trees of similair objects, for example part lists. In that scenario I strongly recommend to use IDs that are generated by the client (preferably Guids). There is no problem to save a new partial tree if Guids are used. In case of autogenerated IDs you have to take care that you store one layer of the hierarchy after the other, so that NDO is able to change the foreign keys after the primary keys have been generated by the database. You can specify to use Guids using the attribute [NDOOidType(typeof(Guid))] which works assembly-wide as well as for certain classes. NDO takes that attribute into account when creating the database structure and also creates an ID automatically if MakePersistent is called for an object. Best Regards, Mirko
  NDO-Forum postings in english please, if possible.  Developing with NDO  Comparison with...
  SearchSearch  Forum HomeForum Home