1
Vote

Persistence provider for SQL Server

description

First persistence provider to implement would probably be for SQL Server/RDBMS in general if possible. This will constitute referential implementation for flow state persistence providers, so some decisions yet need to be lied down. For example due to the lack of awereness of concrete implementation of FlowState object on provider side we could go one of the following routes:
1) Persist using binary serialization
2) Require concrete implementations to provide some kind of serialization mechanism (string to string dictionary would be good I think) via abstract methods like GetStateData or similar (ISerializable?)
3) Use reflection to deduce what needs to be persisted
4) ... more?

Each of the above has some pros and cons. Persisting via binary serialization may lead to versioning incompatibilities. Second one adds some overhead for library users. Reflection can lead to performace issues (although we may probably emit some code to work as serializer during wizard registration time - so we would have some performance loss during initialization only not each call time - see how AutoMapper is implemented).

comments

merdacz wrote Mar 6, 2010 at 6:24 AM

Counterintuitively (at least for me) it seems that Binary Serializaition is quite expensive. More information can be found here: http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx

merdacz wrote Mar 6, 2010 at 6:32 AM

Also I think that SQL Server may not be best choice here. Some document based database may be a best fit.