Will an analogous attribute be available?

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Feb 24 '10 at 23:17

ara's gravatar image

ara
395868791


One Answer:

Earlier I thought it's enough easy to use public non-persistent field wrapping private persistent to get nearly the same functionality. But this approach doesn't allow you to use LINQ queries for such types with ease, although implying you can add your own compilers, you can solve even this problem. But... This isn't really usable.

Moreover, we have an issue related to this: the approach we currently use for byte[] fields isn't good enough: arrays are mutable, and currently we don't return a new array each time it is requested by user (again, because this isn't cheap). So to deal with such arrays safely, you should anyway hide them just in private persistent fields.

The ideal solution here is to provide some immutable wrapper for byte[] - e.g. of Blob type, and allow to use it as possible persistent field value. Certainly, we must support it in LINQ.

As you see, this is very close to the original problem (wrapping the underlying stored value into mutable or immutable wrapper), and we need a common approach for dealing with such issues.

I'll try to describe possible implementation options related to this today in the evening.


We can implement two versions of such API:

1) IFieldValueAdapter-based version. In general, it turns such fields into mutable wrappers exposing them. There are already two of such wrappers - EntitySetBase and Structure. So it's clear to what such an API might look like. The only thing we must design here is to allow model builder to properly map persistent fields of new (custom) types to underlying columns (fields). LINQ can be extended via already existing APIs.

Pros: explicit mutability of such fields.

Cons: IFieldValueAdapter implies it explicitly knows the owner (Entity it belongs to), which is not always desirable (e.g. this isn't really important for Blog type). Mutability isn't always desirable as well.

2) An new API allowing to bind any (incl. custom) types with FieldAccessor<t> descendants providing custom mapping (this part isn't implemented now - this is currently in sole responsibility of domain builder) and conversion\assignment related logic (that's what already provided there).

Pros: best for immutable things \ wrappers.

Cons: won't work for mutable wrappers (because a new object will be returned each time FieldAccessor<t>.GetValue method is invoked; the only difference is case 2).

So likely (I see this after writing all this stuff ;) ), we must implement a combined approach. We must:

  • Extend FieldAccessor<t> by allowing it to provide mapping (= participate in model building process);

  • Allow (= pick up automatically from DomainConfiguration.Types, as we do this for any other service) users to inject custom field accessors to the Domain;

  • Allow these accessors to be inherited from CachingFieldAccessor<t> providing support for IFieldValueAdapters (if it is used for a particular field, a special "slot" is reserved in EntityState to store the adapter object after its creation).

"Allow" = convert internal types to public & provide necessary extension points.

That's it. And certainly, we must provide some examples.

answered Feb 25 '10 at 11:32

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Issue: http://code.google.com/p/dataobjectsdot ... ail?id=614

For not it isn't scheduled (Milestone-Future).

(Feb 25 '10 at 11:32) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×573

Asked: Feb 24 '10 at 23:17

Seen: 2,076 times

Last updated: Feb 24 '10 at 23:17

powered by OSQA