I am using StructureMap and Castle for DI/IoC/Proxy Objects. When retrieving a document, I would like to generate a proxy on that object so I can still utilize interceptors for things like INPC and Logging. I implemented IDocumentConversionListener, and added the logic to create a proxy object, but RavenDb is still handing back the non-proxied object.
public void DocumentToEntity(object entity, Raven.Json.Linq.RavenJObject document, Raven.Json.Linq.RavenJObject metadata) {
var proxyModel = ProxyGenerator.CreateClassProxyWithTarget( entity.GetType(), new Type[] { typeof(INotifyPropertyChanged) }, entity, ProxyGenerationOptions.Default, new ModelInterceptor());
entity = proxyModel;
}
Is it not possible to manipulate the object in this listener? Or should I just be doing this in a completely different place?
On Wed, May 16, 2012 at 11:03 PM, JT <jth...@gmail.com> wrote:
> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When
> retrieving a document, I would like to generate a proxy on that object so I
> can still utilize interceptors for things like INPC and Logging.
> I implemented IDocumentConversionListener, and added the logic to create a
> proxy object, but RavenDb is still handing back the non-proxied object.
Having a hard time finding documentation on these listeners. Can you explain what the benefit is to having the entity object being passed? Trying to figure out why this would be exposed to me if it isn't the actual 'entity' that get's passed to me from RavenDb.
On Wednesday, May 16, 2012 6:03:16 PM UTC-4, JT wrote:
> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When > retrieving a document, I would like to generate a proxy on that object so I > can still utilize interceptors for things like INPC and Logging. > I implemented IDocumentConversionListener, and added the logic to create a > proxy object, but RavenDb is still handing back the non-proxied object.
On Thu, May 17, 2012 at 2:00 AM, JT <jth...@gmail.com> wrote:
> Having a hard time finding documentation on these listeners. Can you
> explain what the benefit is to having the entity object being passed?
> Trying to figure out why this would be exposed to me if it isn't the actual
> 'entity' that get's passed to me from RavenDb.
> On Wednesday, May 16, 2012 6:03:16 PM UTC-4, JT wrote:
>> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When
>> retrieving a document, I would like to generate a proxy on that object so I
>> can still utilize interceptors for things like INPC and Logging.
>> I implemented **IDocumentConversionListener, and added the logic to
>> create a proxy object, but RavenDb is still handing back the non-proxied
>> object.
Ok thanks. I'm looking forward to more documentation on listeners. Or even introducing some new listeners that will let you manipulate the actual entity that gets casted to the domain object during a session.Load<TheObject>(id);
I guess I'm a bit spoiled by NHibernate which gave us the ability to attach our own interceptors to the proxied object being handed back.
As of right now, it looks like I have to proxy the object manually after every query, but I'm going to look a bit deeper into the JsonSerializer & play with the metadata coming back.
On Wednesday, May 16, 2012 6:03:16 PM UTC-4, JT wrote:
> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When > retrieving a document, I would like to generate a proxy on that object so I > can still utilize interceptors for things like INPC and Logging. > I implemented IDocumentConversionListener, and added the logic to create a > proxy object, but RavenDb is still handing back the non-proxied object.
I wonder if AutoMapper would help with what you're trying to do?
According to the AutoMapper.org website it is, "...built to solve a
deceptively complex problem - getting rid of code that mapped one
object to another."
Disclaimer: I am not associated with, nor have I ever actually used AutoMapper.
On Thu, May 17, 2012 at 8:37 AM, JT <jth...@gmail.com> wrote:
> Ok thanks. I'm looking forward to more documentation on listeners. Or even
> introducing some new listeners that will let you manipulate the actual
> entity that gets casted to the domain object during a
> session.Load<TheObject>(id);
> I guess I'm a bit spoiled by NHibernate which gave us the ability to attach
> our own interceptors to the proxied object being handed back.
> As of right now, it looks like I have to proxy the object manually after
> every query, but I'm going to look a bit deeper into the JsonSerializer &
> play with the metadata coming back.
> On Wednesday, May 16, 2012 6:03:16 PM UTC-4, JT wrote:
>> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When
>> retrieving a document, I would like to generate a proxy on that object so I
>> can still utilize interceptors for things like INPC and Logging.
>> I implemented IDocumentConversionListener, and added the logic to create a
>> proxy object, but RavenDb is still handing back the non-proxied object.
On Thu, May 17, 2012 at 2:37 PM, JT <jth...@gmail.com> wrote:
> Ok thanks. I'm looking forward to more documentation on listeners. Or even
> introducing some new listeners that will let you manipulate the actual
> entity that gets casted to the domain object during a
> session.Load<TheObject>(id);
> I guess I'm a bit spoiled by NHibernate which gave us the ability to
> attach our own interceptors to the proxied object being handed back.
> As of right now, it looks like I have to proxy the object manually after
> every query, but I'm going to look a bit deeper into the JsonSerializer &
> play with the metadata coming back.
> On Wednesday, May 16, 2012 6:03:16 PM UTC-4, JT wrote:
>> I am using StructureMap and Castle for DI/IoC/Proxy Objects. When
>> retrieving a document, I would like to generate a proxy on that object so I
>> can still utilize interceptors for things like INPC and Logging.
>> I implemented **IDocumentConversionListener, and added the logic to
>> create a proxy object, but RavenDb is still handing back the non-proxied
>> object.
On Thursday, May 17, 2012 9:52:17 AM UTC-4, Bryan Johns wrote:
> I wonder if AutoMapper would help with what you're trying to do?
> According to the AutoMapper.org website it is, "...built to solve a > deceptively complex problem - getting rid of code that mapped one > object to another."
> Disclaimer: I am not associated with, nor have I ever actually used > AutoMapper.
