Amen to the VM/Control separation. I'm working with some existing code, so I don't have as much latitude as I'd like, but in my mind, the control should contain rendering code only (when the available UI widgets are lacking, for animation, etc). The ViewModel should contain all the logic/collections/etc for the control. With SL4 and commands, we are able to get a lot closer to that goal. I hope we're all the way there soon.
If I have the generic parameter on the base class (I assume you mean base ViewModel), doesn't that imply that I then have to pass an untyped query to the repository? Then do a Cast<DataObject> operator on the way back (if needed)? I can't see any technical reason that it wouldn't work, but it seems dangerous somehow. Have you used a purely non-generic repository style system before? Any problems? Thanks, this has been extremely valuable! Erick On Wed, Mar 3, 2010 at 10:39 PM, Kelly Leahy <[email protected]>wrote: > Actually, I think in that case your best bet is to have the generic > parameter on the base class. Why is it that you don't like that? > > Glenn's project that I was referring to is a side project, AFAIK, that > he was working on for binding using a fluent interface in code, rather > than specifying your bindings in XAML. AFAIK, it's still in the > "exploratory" stages, but I'm sure he'd love to talk about it with you > if he has time. > > I think the control shouldn't have any of this stuff in it, though. > It seems to me that the control code should be empty if at all > possible. All of the "view" logic should be in the VM. I don't take > as strong a view of the VM/M separation as some people do. In my > opinion it's ok to have a lot of code in the VM, so long as that > aligns with your testing needs and goals. Our issue right now is that > it doesn't ;) > > Kelly > > On Wed, Mar 3, 2010 at 10:31 PM, Erick Thompson > <[email protected]> wrote: > > Kelly, > > > > Thanks for the great response. I agree with your comments about > inheritance > > (it is usually ugly). I love the idea about making the interface > non-generic > > and moving the generic parameter to the method. One key detail that I > forgot > > to mention is that this is a platform, and not an application, hence my > > inability to know what T is. > > > > I completely agree about keeping very little code in the ViewModel > (except > > for UI specific code). My ultimate goal is to have a 100 level programmer > be > > able to create a new ViewModel with very little knowledge of how it > works, > > and do most of the presentation customization via XAML. The base VM > contains > > all the plumbing to actually make things happen, and the derived VM is > the > > one used by the dev. They would be expected to write something like the > > following. > > > > class MyDataObjectViewModel : FooViewModel { > > public override IQueryable<DataObject> Query(IQueryable<DataObject> > > basequery) { > > var query = from d in basequery > > select d; // or some other LINQ query) > > > > return base.Query(query); > > } > > } > > > > The base ViewModel actually handles the population and management of the > > items in the resulting collection (which the UI/Control binds to in a > > non-generic way). If I'm not mistaken, having the generic parameter on > the > > method should work for this. I'll have to try it out in the morning. > > > > Aside from that, do you see a better way to do this? I generally don't > like > > inheritance, but it seems like a good way to keep the messy details away > > from the end user/dev. > > > > Also, as an aside, which project of Glenn's are you referring to? It > sounds > > interesting... > > > > Thanks, > > Erick > > On Wed, Mar 3, 2010 at 8:24 PM, Kelly Leahy <[email protected]> > wrote: > >> > >> If we take a step back, and think about what you're saying, I think > >> you'll realize it doesn't make sense. > >> > >> It sounds like you're saying you want to have some generic object that > >> you hold onto in your class but you don't want to know what the type > >> of that object is. However, you want to be able to write code that > >> uses that object. There's not any sensible way that the compiler > >> could type-check your code without knowing what T is, which is why you > >> either need to specify a value of T in your field (i.e. bind the > >> parameter to a type), or you need to make T a generic parameter of > >> your type (i.e. leave it as an 'open' generic and 'provide' the T from > >> the use site of your class). > >> > >> The thing I'm not really getting is why the control author cares what > >> T is. It seems to me that if you're doing VM / PM pattern well, you > >> should be striving to have very little (if any) code in your controls, > >> and all of the interaction should be through bindings to the VM (which > >> are - by definition - untyped, though if you use something like the > >> binding frameworks that Glenn has been trying to build, you'll see > >> that you can use stronger typing in your bindings). > >> > >> What you can do, and I've done this in the past, is not make the > >> repository generic, but rather make its methods generic (i.e. > >> Query<T>(...) instead of IRepository<T>::Query(...)) but this won't > >> allow you to resolve different repositories by type from the IoC > >> container. > >> > >> The other thing I'd ask yourself is whether inheritance is the right > >> solution to your problem. In nearly every case in my past that I > >> thought it was, I turned out to be wrong. You might also think about > >> whether the type of the repository is important to be in a base class, > >> or whether you can get the same effect by having the base class be > >> abstract, providing a few methods to 'hook' into the derived class > >> implementations, and then you can have the type parameter on the base > >> class and have the deriving class provide the "T" when it derives. In > >> other words, you could make: > >> > >> public class FooContainerControl: ContainerControlBase<Foo> { ... } > >> > >> We do this a lot in our UI code (though we do it with the PMs, not the > >> controls, I personally hate base classes for controls - it never works > >> out well, we use interfaces exclusively for them). For instance, we > >> have a: > >> > >> public class EditorGridPresentationModelBase<T> where T: IItemCore, > class > >> { ... } > >> > >> and then for Table and Variable (both IItemCore implementers), we have > >> > >> public class EditorGridPresentationModel: > >> EditorGridPresentationModelBase<Table> > >> { ... } > >> (in the Tables namespace), and > >> > >> public class EditorGridPresentationModel: > >> EditorGridPresentationModelBase<Variable> > >> { ... } > >> (in the Input namespace). > >> > >> Kelly > >> > >> On Wed, Mar 3, 2010 at 4:10 PM, Erick Thompson < > [email protected]> > >> wrote: > >> > I have run into a situation where I can't see any good solutions, and > >> > I'm > >> > hoping someone has run into a similar situation. > >> > > >> > I have a generic IRepository<T> interface which is used for loading > data > >> > from a store. I have the generic parameter as I want to allow typed > >> > queries > >> > (the queries will end up hitting a ANDS service). I want to use > classes > >> > implementing interface this in custom controls and ModelViews in a > >> > Silverlight 4 application. > >> > > >> > The problem is that you can't have a generic interface in a class > >> > without > >> > having a generic type on the class. > >> > > >> > public class ControlBase { > >> > protected IRepository<T> _repository; > >> > } > >> > > >> > will not compile. As this is a base class, I can't specify the T > unless > >> > I use a inherited base DataClass. I would like to use POCOs if > possible. > >> > > >> > In the fantasy world in my head, I would simply make the base class > >> > generic, > >> > and Bob's your uncle. However, I want these classes to be easily > >> > consumed in > >> > XAML, which doesn't have a good way to instantiate a generic type. > >> > > >> > What I ultimately want is for the user to be able to create the > >> > control/form > >> > (bound to ModelView) without a generic type, but that the data access > >> > occurs > >> > in a typed way. For example: > >> > > >> > public class CoolControl : ControlBase { > >> > public CoolControl() { > >> > _repository = IoC.Resolve<IRepository<SomeConcreteDataType>>(); > >> > } > >> > > >> > public LoadData () { > >> > // do some typed IQueryable stuff on repository > >> > } > >> > } > >> > > >> > With this, the user can specify the control/ViewModel in XAML, and the > >> > control/ViewModel author gets the benefit of typing. > >> > > >> > Is there any good way to do this or I am stuck? > >> > > >> > Thanks, > >> > Erick > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "Seattle area Alt.Net" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<altnetseattle%[email protected]> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/altnetseattle?hl=en. > >> > > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Seattle area Alt.Net" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<altnetseattle%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/altnetseattle?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Seattle area Alt.Net" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<altnetseattle%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/altnetseattle?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
