When you're designing an API you and your users will hook to, one of the most important thing is to provide a simple-to-use API and that has even more importance when you're trying to develop an object-oriented API to access your database. There are a lot of ORM tools which allow developers to map their database tables into objects and make it easy to work with them. And besides, there's also LINQ. Developers are getting used to exploit such tools to do something like this:

MyObject.MyField="MyValue"

MyObject.Save()

And then they retrieve by

MyObject.Load(MyKey)

This kind of code has unmatched advantages, expecially when it's easy to generate objects like in CoolStorage case and that makes developing a lot easier. So when you're dealing with objects databases, you expect to be able to leverage such easyness in coding, if not a lot more than that. Sure, working with your objects, instead of having to deal with Access / MySQL / SQL Server databases, is a lot easier expecially when you don't need to generate or use all those proxy objects. While I'm close to finalize API for a few Diavolo area, expecially in pages / portal management, I wanted to change something I left unaddressed for a few months, meaning I was aware of the "problem" but I didn't want to solve this now.

Perst objects (those inheriting from Persistent) have a method named Store() (or Modify()) to save changes back to database. However, there's a problem with those methods because if you get an object out of database and then close that database (i.e. associated Storage object) then you will get "Value cannot be null" error if you call Store() or Modify() (or Deallocate() for example) because Perst is not able to reopen that database when needed. Basically an object taken out of a closed database will be invalid when trying to save them back without opening a database again. Even when you open a new database, you won't be able to save them by simply invoking Store() because such objects cannot be automatically mapped to another storage object. An annoying problem which forced me to develop a class to implement saving back to db. Something like :

Diavolo.v4.Core.Kernel.PagesManager.SavePage(PageObject)

That's not a so terrible thing but for sure that's not as handy and simple as

PageObject.Store()

or

PageObject.Save()

That's why I wanted to provide API users a simpler way to cope with my objects.

Subclassing Persistent class

The next obvious attempt was to subclass Persistent class in order to override/overload methods like Store(), Deallocate(), Modify() and all of them involved into interaction with database but, once you do that, you will find that, for whatever reason, you won't be able to save your objects back to database because calling a method like

Storage.storeObject(PageObject)

will call back your overloaded / overridden Store() method, thus breaking our code. I don't know which is the reason why storeObject method will call back object Store() method, there should be a reason for that in main Perst code, but that will make prevent to override those standard methods so a new solution is needed.

I came up to implement new methods for my objects, namely a Save() and Delete() method in order to provide users a quick way to work with objects. Sure, that means that calling Store() method on such objects will generate an exception but until I find a new, better solution, that's for sure simplest way to let users manage their objects. I probably need to talk Perst guys about that but right now that look to be the best solution.