Persistence class converted to provider model

Topics: Developer Forum
Dec 28, 2006 at 2:55 PM

first of all, thank you for this nice project. Though it aims to simplicity, it provides a basic starter kit for all developers and can be easily extended. I have many ideas for this and will probably release some modifications.

Anyway, first idea which came to my mind was: why not turning Persistence mechanism (which is very nice, indeed. Very easy to use and implement) into a provider model mechanism? This way, people interested in using SQL Server as a store instead of XML files, could simply write a custom provider. That would be a very easy way to provide those functionalities. And it would then be easier to use Access or SQL Server as store and the best thing would be additional sections won't need any change to use that because of nice persistence mechanism.

Just an idea ;-)

Thank you again and merry Xmas to all of you! ;-)
Dec 29, 2006 at 3:37 AM
I think this is a great idea!
Jan 3, 2007 at 12:45 PM
Dear user
thanks for your idea. We always appreciate users suggestions! I suppose you are talking about Provider Model Implementation, which supplies the mechanism of persist user data.

Since the Starter Kit does not allow users to personalize their website, I suppose the implementation of a persistence class needs to be considered very well. In the current version the storing of data in e.g. SQL-Server is possible through a Easy-Control.

Best regards,
Jan 3, 2007 at 2:01 PM
Hello webeasy,

thank you for being so responsive.

My suggestion was about implementin Persistence class as a provider rather than a static class. This way, given your nice persistence mechanism, by switching provider user could switch actual store for data. Plus, that would make persistence functionalities transparent to sections, which could keep using the old way of storing data regardless where data will actually be stored (file system, Access DB, SQL Server DB, MySQL, Oracle etc.), provided that a provider for that store is implemented.

Thank you for your support.
Jan 4, 2007 at 11:22 AM
Hello TBPrince

I am not sure if I understood you completey. Are you talking about a layer between WebSite.cs and Persistable.cs ?

And where should the source for storing data be set ?

Best regards,
Jan 6, 2007 at 3:07 PM
Hello webeasy,

right now persistable.cs is a partially-abstracted class, since it implements SaveData() and LoadData(), which in turn serialize or deserialize data to / from disk. If persistable.cs was a fully abstract class, whose implementation was exposed in web.config (the same way we set up which Membership API class we want to use via web.config), users could just replace actual persistable.cs implementation.

Each implementation could implement its own SaveData() and LoadData(), for example serializing and deserializing to a database instead of file system, the same way membership classes implements their own storage strategies according to which class we use.

I hope I was clear enough. English is not my mother-language ;-)

Take care.
Jan 7, 2007 at 8:22 AM

Wouldn't be easier, as a first attempt, to have a parameter in the web.config file which defines where data to be saved in a database or in a file system and all the necessary changes be made in the SaveData() and LoadData() functions?
Jan 8, 2007 at 4:09 PM
Yes, it would be easier. However, if people starts to contribute with sections / add-ons, it would be important that storage / persistence mechanism stays the same.

One of the worst plagues affecting other CMS when dealing with multiple databases support is just that modules (sections) usually need to be change for each database system because storage mechanism is not abstract.

MWPSK storage mechanism is very keen to be abstract and this way you don't need to write your own functions to save or load data: everything is done for you by system itself. The goal of making this system even more abstract is to allow developers to create new sections without caring WHERE their data will be stored. It might be a database or file system or whatever: they just need to SaveData() and LoadData().

That would boost number of sections which will be available in near future and make developers' life easier.

Take care.
Jan 11, 2007 at 3:38 AM
I agree, all these are technically correct. However, we should avoid making the same "mistakes" with DNN equivalent, i.e. complexity and most of all, after so many versions still it doesn't support multilingual content!!! I think if MWPSK supports multilingual content and the storage mechanism can be either file or Database and at the same time keep its simplicity; its impact will be greater than DNN's.
Jan 11, 2007 at 8:07 AM
I agree about this. Supporting multiple languages from the beginning is crucial and that's why I could never use DNN (can't believe they have no decent ML support yet!). The best support for this feature comes from Rainbow Portal. Sections should also include a setting to be shown only to specific cultures.

I also believe that Website class should include a way to store global settings (like a Dictionary of strings, for example).
Jan 11, 2007 at 3:09 PM
At the moment all the data is persisted in the App_Data Folder. Since the loading of Data, Sections and ASP 2.0 Controls is strictly connected with this folder in many files, the abstraction of the persisting mechanism is not that easy.
you can see that, when you make a global search with "App_Data".

Since the implementation is concerning the whole application (Reset mechanisme, SiteMap, Membership, Error Logging, Sections, etc.)
I think its better to wait for some more user feedbacks.