I have a requirement to build a 'base' profile library (in C# - NET 4.5.2) for various different internal (technical) consumers. This profile consists of metadata fields that would be shared by a wide-variety of different profile implementations. The metadata for these different profiles is stored in a single location but each actual implementation for the base profile will have it's own data storage (which I'll know nothing about).
Rather than provide an actual service we will only be providing the base classes / interfaces necessary to allow developers to implement their own profile services.
Ideally, I'd like to make the hydration of the base profile's metadata fields completely automatic for developers - they focus on hydrating their own fields in their child class only.
My requirements are:
- Base profile all other profile objects must inherit
- Base profile self-hydrates from a static data source that is opaque to implementors.
- The ability to query for many profiles based on a predicate, a profile ID list, or both.
- CRUD operations for a given profile that permit said operations on the base profile metadata in addition to whatever the user needs to do in their own system(s).
On idea that has been floated already includes allowing developers to provide a generator function (Func<Guid, Profile<T>>
) where Guid is the Id of the profile (for existing reads) and the function executes whatever logic the developer requires to initialize their profile while at the same time getting the base profile data.
I'd be curious to hear the communities thoughts on this though (and whether or not this is even a good course to chart).