I'll answer backwards. Why am I using an IoC container? Well, right now, the repository is very simple - it takes a query and runs it against an ANDS service and returns the results. However, a great deal of the data in these queries is almost read-only (changes maybe once a year), and the target audience consists of users with very limited bandwidth. So in the future (v1.x), we want to be able to have a different repository, one that teases apart the query and uses local data where possible. I could use inheritance to do this, but it seems like a better fit for IoC, as I don't need to mess with the original repository. Also, it makes testing much easier. :-)
As for what I am trying to do, I outlined that it my response to Kelly. It's a platform that consists of a VM and a specialized control that leverages the VM. The control really isn't useful without the VM. Instances of the control + VM will be created by junior devs, and so the intent is to create a derived VM that is dead easy to use, where all you need to do is plug in a LINQ query. Having Type information makes writing LINQ queries _much_ easier and less error prone. The interface currently consists of two properties (more will be added later, but they aren't generic). IQueryable<BaseDataObject> QueryBase; IEnumerator<BaseDataObject> Query(IQueryable<BaseDataObject> query); The base VM exposes QueryBase for modification to the 100 level VM, and then passes that query to the Query method on the repository. The base VM then handles the population of the appropriate collections that the control is bound to. Does this make more sense? Thanks, Erick On Wed, Mar 3, 2010 at 10:27 PM, Justin Bozonier <[email protected]>wrote: > I agree with Kelly here. I'd be interested to see the code you have > now and see the code you'd like to change it to (whether or not it > compiles) just to get a complete set of thoughts from you. > > Also, no cool control I know would take a dependency on an IOC container. > :) > > 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]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
