Repository navigation
Add Automapper support #106
Description
I've seen a bunch of feedback from folks (lie @AlexZeitler) feeling it is too painful to have to implement document readers and writers. So I am thinking to just add Automapper support in the box (though possible as an add-on for those that don't want it).
- By default it would have some simple out of the box mapping rules.
- For more advanced cases would be able to customize the Automapper mapping.
The goal would be to reuse the existing abstractions (reader/writer), but you would have a strongly typed MappedReadDocument<T> / MappedWriteDocument<T> or something.
Thoughts on if this is worthwhile / and if so what you'd like to see done? I am definitely NOT the AM expert :-)
Activity
AlexZeitler commentedon Nov 30, 2014
Good to see you're thinking about AM-Support. Would be good if you spin up an "internal" instance of the AM
MappingEngineas otherwise mappings might conflict with definitions used by theMapperstatic instance provided by AM by default.glennblock commentedon Nov 30, 2014
@AlexZeitler thanks, well you had something to do with it :-) Do you think it makes sense? Would it satisfy your needs if for example you could register say a generic MappingReadDocument<>, MappingReadDocument<> for handling the default cases, and then register specific closed ones for cases where you need to control the configuration? Or would you prefer a diff approach?
glennblock commentedon Nov 30, 2014
Gotcha on the internal instance. Would it make sense to allow one to pass in their own instance?
AlexZeitler commentedon Nov 30, 2014
At the moment I don't see a real advantage of being able to pass in my own instance. Also you could use
configuration.Initialize()(if not passing in a custom instance) which improves mapping perf if im not totally wrong.WRT to
MappingReadDocument<>: it would make sense.On the other hand, as already explained, the key issue for the team (I've been working with as an external) with the Reader / Writer approach is the dependency on CJ inside the controllers.
Don't you see scenarios where it makes sense to provide an API serving e.g. CJ and HAL in parallel?
If not, why? If yes, how would you deal with that?
glennblock commentedon Nov 30, 2014
@AlexZeitler I do see that would be valuable. But document reader and writer are interfaces deliberately. There's no problem having a single class implement both interfaces / be an adapter. I am not a huge fan of the idea of one generic interface to rule them all as I believe it will end up as a leaky abstraction and media types vary greatly.
AlexZeitler commentedon Nov 30, 2014
What do you think of a base class that provides support for all H-Factors and a concrete impl. maps the factors to the concrete HM type?
I think it is difficult to provide the HM generation in a generic manner especially when it comes to linking that requires problem domain context (e.g. paging).
glennblock commentedon Nov 30, 2014
This is what The Hypermedia Project is attempting (in multiple languages).
Basically providing a way to express H-Factors and then have utilities to
then express those in whatever format you like. Having been doing similar
roads in the past, I am a skeptic. I think it is possible, but that it will
get very ugly.
On Sat Nov 29 2014 at 6:44:40 PM Alexander Zeitler notifications@github.com
wrote:
glennblock commentedon Nov 30, 2014
@AlexZeitler I am part of The Hypermedia Project because this is something they are focusing on and though I am skeptical, I am willing to be proven wrong. If it turns out I am, I'll gladly be more willing to embrace :-)
AlexZeitler commentedon Nov 30, 2014
For Web API I've a rough idea how it could be solved using AM and a IoC-Container, but I dunno about Nancy.=
glennblock commentedon Nov 30, 2014
@AlexZeitler @jchannon has it working currently with my library for Nancy. He wrote Nancy.CollectionJson for this purpose.
glennblock commentedon Nov 30, 2014
@AlexZeitler you mean how you can solve having the one model to rule them all?
AlexZeitler commentedon Nov 30, 2014
yes.
glennblock commentedon Nov 30, 2014
@AlexZeitler well if you look at The Hypermedia Project they already have it. Just hasn't been ported to .NET yet.
AlexZeitler commentedon Nov 30, 2014
Is HyperMedia project != DotNetHyperMedia project? Do you have a link?
glennblock commentedon Nov 30, 2014
Not the same. The first has been around for 6 months. It started when a bunch of us were at Api Craft in Chicago. https://github.com/the-hypermedia-project/charter