I'm looking for opinions about this subject.. EnhancedBytecode provider and the ReflectionOptimizer works great to resolve entities with the IoC container. However, there are some cases that is not enough. For instance, when you add a custom interceptor, or an additional interface the container will resolve as a "Proxy32132131232132", in such cases nhibernate can't find a suitable persister. From here I will talk only for castle adapters.
My workarround will be to add a: -GetNameInterceptor (Method Call Interceptor - Castle) -INhibernateNamedEntity (additional interface for this kind of components) -EntityNameInterceptor (Nhibernate Interceptor) -Maybe an InterceptorSelector
I would be very interested in using something like this, though I
wonder of some people will feel that introducing UI concerns in the
domain would be polluting the domain?
For my last project I used nHibernate with a WPF UI and it worked out
extremely well. I ended up using MVVM and viewmodels which
encapsulated the data from my entities. I had a ViewModelBase class
implementing some custom IEditiableObject logic and I used
INotifyProperty changed on the viewmodels, which is a standard
requirement for a viewmodel though only for a total undo, not N undo/
redo.
I did however make some early attempts at binding entities directly by
having them inherit a base class that implemented
INotifyPropertyChanged and adding PropertyChanged("PropertyName") to
all my properties. I definitely see the potential creating nHibernate
entities that implement INotifyPropertyChanged and IEditableObject and
binding directly WPF UserControl views.
Another idea might be providing save/update and delete as ICommand
(s). Also a sort of build in lazy-loading functionality for entities
with one-to-many relationships would be another. I implemented my
lazy loading in the viewmodel so that when the collection was accessed
it would perform a query for it. I find the trickiest thing about
nHibernate and WPF is determining the best way to manage your sessions
and where, having that handled in a sensible manner for a WPF app
would be a dream.
I'm looking forward to hearing some more of your ideas for WPF-aware
entities. I can see a lot of potenitial for this. I would be very
happy to contribute if I can in any way.
> I would be very interested in using something like this, though I > wonder of some people will feel that introducing UI concerns in the > domain would be polluting the domain?
> For my last project I used nHibernate with a WPF UI and it worked out > extremely well. I ended up using MVVM and viewmodels which > encapsulated the data from my entities. I had a ViewModelBase class > implementing some custom IEditiableObject logic and I used > INotifyProperty changed on the viewmodels, which is a standard > requirement for a viewmodel though only for a total undo, not N undo/ > redo.
> I did however make some early attempts at binding entities directly by > having them inherit a base class that implemented > INotifyPropertyChanged and adding PropertyChanged("PropertyName") to > all my properties. I definitely see the potential creating nHibernate > entities that implement INotifyPropertyChanged and IEditableObject and > binding directly WPF UserControl views.
> Another idea might be providing save/update and delete as ICommand > (s). Also a sort of build in lazy-loading functionality for entities > with one-to-many relationships would be another. I implemented my > lazy loading in the viewmodel so that when the collection was accessed > it would perform a query for it. I find the trickiest thing about > nHibernate and WPF is determining the best way to manage your sessions > and where, having that handled in a sensible manner for a WPF app > would be a dream.
> I'm looking forward to hearing some more of your ideas for WPF-aware > entities. I can see a lot of potenitial for this. I would be very > happy to contribute if I can in any way.
> I would be very interested in using something like this, though I > wonder of some people will feel that introducing UI concerns in the > domain would be polluting the domain?
Yes, I know that and this is something that I am taking into account. I want t show you two classes:
As you can see Album hasn't UI stuff. Entity is a class from unhaddins that has some nice stuff but none of them related to UI.
> For my last project I used nHibernate with a WPF UI and it worked out > extremely well. I ended up using MVVM and viewmodels which > encapsulated the data from my entities. I had a ViewModelBase class > implementing some custom IEditiableObject logic and I used > INotifyProperty changed on the viewmodels, which is a standard > requirement for a viewmodel though only for a total undo, not N undo/ > redo.
You could look the above sample, this will be supported. Note that also you could add another interface to the proxy, lets say : Public interface IEditableAlbum : IEditableObject, IAlbum {}
> I did however make some early attempts at binding entities directly by > having them inherit a base class that implemented > INotifyPropertyChanged and adding PropertyChanged("PropertyName") to > all my properties. I definitely see the potential creating nHibernate > entities that implement INotifyPropertyChanged and IEditableObject and > binding directly WPF UserControl views.
INotifyPropertyChanged is another behavior, you could see my post on the subject... http://jfromaniello.blogspot.com/2009/07/inotifypropertychanged-as-ao... It will work like IEditable. So you can plug: public interface INotificableEditableAlbum : IEditableObject, INotifyPropertyChanged, IAlbum
> Another idea might be providing save/update and delete as ICommand > (s).
I think that ICommand is related to View -> ViewModel comunication and has nothing to do with the Model itself.
> Also a sort of build in lazy-loading functionality for entities > with one-to-many relationships would be another. I implemented my > lazy loading in the viewmodel so that when the collection was accessed > it would perform a query for it.
Is one of the reason that I will not "encapsulate" domain entities with an extra model, let nhibernate deal with lazy loading and bind directly to domain entities.
> I find the trickiest thing about > nHibernate and WPF is determining the best way to manage your sessions > and where, having that handled in a sensible manner for a WPF app > would be a dream.
Like Fabio said; CpBT.
> I'm looking forward to hearing some more of your ideas for WPF-aware > entities. I can see a lot of potenitial for this. I would be very > happy to contribute if I can in any way.
Finally, thank you very mutch for your comments and the comment on my blog, stay in touch with this project. It is *very*, very, very important for me to read opinions.
|
