Krokonoster
Jan 18th, 2011, 02:38 PM
Just been critisized by someone more senior/smart than me about me resolving ViewModelDependencies inside the ViewModel itself. However the reason was "I just dont like it", which I could not swallow.
Apparantly it's prefered giving the Controller class a dependency (which it wont use), and then pass that dependency into the constructor of the ViewModel (which IMO is not right...giving the controller class a responsiblility of resolving a ViewModel's dependency?)
This is what I do in my ViewModel (by the way, the dependencies are necessary due to the project architecture. I cannot go change it):
public class ClientModel
{
private readonly IAccountRepository _accountRepository;
public ClientModel()
{
_accountRepository = ObjectFactory.GetInstance<IAccountRepository >();
}
So, what's wrong with this? What is a better way?
IMO this is nice. The ViewModel can stand alone and have it's dependencies resolved without know the implementation. (It work by the way...just not sure if it's an anti-pattern)
Apparantly it's prefered giving the Controller class a dependency (which it wont use), and then pass that dependency into the constructor of the ViewModel (which IMO is not right...giving the controller class a responsiblility of resolving a ViewModel's dependency?)
This is what I do in my ViewModel (by the way, the dependencies are necessary due to the project architecture. I cannot go change it):
public class ClientModel
{
private readonly IAccountRepository _accountRepository;
public ClientModel()
{
_accountRepository = ObjectFactory.GetInstance<IAccountRepository >();
}
So, what's wrong with this? What is a better way?
IMO this is nice. The ViewModel can stand alone and have it's dependencies resolved without know the implementation. (It work by the way...just not sure if it's an anti-pattern)