Geek Answers Handbook

Where can I create dependency creation for the Presenter class in Passive View architecture?

I just reworked a new domain class from a presenter class, but I cannot figure out where to create it.

This is part of a larger ongoing refactoring effort with a poorly preserved obsolete project.

Currently, Presenter is created by the OnLoad view and the view is passed as a parameter in the constructor. All public methods in the presenter are without parameters and return to void. They interact with the view using the publicly available properties of the view.

The view, which is essentially a modest form, is completely dependent on the leader for everything.

This is a typical passive pattern, and I would like to continue to stick to it. This brings me to my dilemma. I need to instantiate my new domain object for use by the presenter.

  • If I pass it through the constructor, then the view should create it and get an unnecessary dependency.
  • If I create it anywhere in the presenter, I cannot replace it with a mock object in my unit tests.
  • If I make this a public property of the host, then I introduce the dependence of the order of creation on the methods of the presenter, where it is used, and I still have not decided which external class receives responsibility for its creation.

I currently do not use any dependency injection frameworks. Although I'm interested in using one in the future, the source code is still very fragile to incorporate a third-party structure into the mix.

I am open to any suggestions.

+4
source share
3 answers

I found a much simpler solution. Here is an example of my original class:

public Presenter(IView view) { this.View = view; }

I wanted to pass on my new dependency as an argument to the constructor, but I would not want to add this dependency to my view. Constructor chain to the rescue!

 public Presenter(IView view):this(view, new Dependency()){} public Presenter(IView view, IDependency dependency) { this.View = view; this.Dependency = dependency; }

Now the production code continues to use the original interface, while unit tests use the new one passed to mocks for both presentation and dependency. If the number of dependencies continues to grow, some refactoring will be required, but for the near future this is an ideal solution.

+1
source

I've already done it!!! Check out my repository here. My choice here is to use the constructor ... satisfying the most greedy, I'm sure the lead is Up. In your case, you can provide a specific impl for dependencies from the view.

enjoy:)

+2
source

At the moment, I would choose a repository or factory. This could be checked right away. In the future, you can replace its implementation to go to the DI library.

 public class DomainObjectsRepository { /// <summary> /// can not be instantiated, use <see cref="Instance"/> instead. /// </summary> protected DomainObjectsRepository() { } static DomainObjectsRepository() { Instance = new DomainObjectsRepository(); } public static DomainObjectsRepository Instance { get; set; } public virtual ICustomerDao GetCustomerDao() { return new CustomerDao(); } } public class DomainObjectsRepositoryMock : DomainObjectsRepository { public override ICustomerDao GetCustomerDao() { return new CustomerDaoMock(); } }
0
source

More articles:


All Articles