Hybrid EAV/CR model via WCF (and statically-typed language)?
- by Pat
Background
I'm working on the architecture for a cloud-based LOB application, using Silverlight for the client, WCF, ASP.NET/C# for server and SQL Server for storage. The data model requires some flexibility per user (ability to add custom properties and define validation rules for them, for example), and a hybrid EAV/CR persistence model on the server side will suit nicely.
Problem
I need an efficient and maintainable technology and approach to handle the transformation from the persisted EAV model to/from WCF (and similarly allow the client to bind to the resulting data - DataGrid is a key UI element)?
Admission: I don't yet know enough about WCF to understand if it supports ExpandoObject directly, but I suspect it will.
Options
I started off looking at WCF RIA services, but quickly discovered they're heavily dependent upon both static type data and compile-time code generation. Neither of these appeal.
The options I'm considering include:
Using WCF RIA services and pass
the data over the network directly in EAV
form (i.e. Dictionary), and handle
the binding issue purely on the
client side (like this)
Using a dynamic language (probably
IronPython) to handle both ends of
the communication, with plumbing to
generate the necessary CLR type data
on the client to allow binding, and
transform to/from EAV form on the
server (spam preventer stopped me from posting a URL here, I'll try it in a comment).
Dynamic LINQ (CreateClass()
and friends), although I'm way out
of my depth there and don't know
what the limitations on that
approach might be yet.
I'm interested in comments on these approaches as well as alternative approaches that might solve the problem.
Other Notes
The Silverlight client will not be the only consumer of the service, making me slightly uncomfortable with option #1 above.
While the data model is flexible, it's not expected to be modified heavily. For argument's sake, we could assume that we might have 25 distinct data models active at a given time, with something like 10-20 unique data fields/rules each. Modifications to the data model will happen infrequently (typically when a new user is initially configured).
