Stan,
IOC Container is not a semantic debate, IOC is about Object A saying
that it requires Object B and Object A not caring where Object B comes
from, or how it is instantiated. This can be achieved via dependency
injection or via the IServiceLocator, or a direct call to the IOC
container, but from somewhere other than the View, IServiceLocator is
a facade to enable us to "swap the IOC Container implementation"
without affecting any of the calling code, so as far as any calling
code goes, IServiceLocator IS the IOC Container.
> but in the implemenation of Microsoft SharePoint practice library
> repository is resolved inside presenter via service locator.
You've nailed it here, "presenter SHOULD be passed an interface to
repository", ideally this will be taken care of by the IOC Container,
either by dependency injection, or by a direct call on the Container.
Nowhere, in what you have said here is there any evidence that your
repository should be instantiated within the View.
In order to test your code in isolation, the best approach would be to
use Dependency Injection, ideally Constructor Injection ....
public class MyPresenter(IRepository repository, IVeiw view) { /* ...
*/ }
Using this approach, you can do something like the following in your
test method ...
// Arrange
var repository = MockRepository.GenerateStub<IRepository>();
var view =MockRepository.GenerateStub<IView>();
var presenter = new MyPresenter(repository, view);
etc.
This is achievable whether or not the IRepository and/or the IView
instances are created within the Presenter instance. If you know that
your Presenter takes care of instantiating these items, and you want
to test your Presenter you can take an approach similar to the
following ...
// Arrange
var repository = MockRepository.GenerateStub<IRepository>();
var view =MockRepository.GenerateStub<IView>();
var serviceLocator = MockRepository.GenerateStub<IServiceLocator>();
serviceLocator.Stub(sl =>
sl.Resolve<IRepository>()).Return(repository);
serviceLocator.Stub(sl => sl.Resolve<IView>()).Return(view);
var presenter = new MyPresenter(serviceLocator);
// Act
/* method call that causes resolutions to be made */
// Assert
/* Assertions to test method being called */
On Feb 15, 6:54 pm, Stan B <[email protected]> wrote:
> Ok, ok it is semantics what is Ioc container and what is not.
>
> Bottom line - presenter should be passed an interface to repository
> but in the implemenation of Microsoft SharePoint practice library
> repository is resolved inside presenter via service locator. Their
> idea is to swap concreate repository class with the mock before
> calling the presenter which again works fine for manual mock classes
> but not with Rhino mocks....
>
> On Feb 15, 11:43 am, bill richards <[email protected]>
> wrote:
>
>
>
> > IServiceLocator : this is your IOC container ... I don't mean to be
> > insulting at all, but I think you need to do some reading around how
> > your APIs work
>
> > I cannot believe you are asking what is wrong with instantiating a
> > repository within a view!
>
> > What is a view? A View is a representation of data, i.e. your view
> > only cares about displaying a set of data, it should have absolutely
> > no idea (nor even care about) where those data come from, the only
> > thing your View should be aware of is the data model to which it will
> > be bound.
>
> > There are some excellent articles on the MSDN web sites which discuss
> > the MVC, MVP, and MVVM patterns etc.
>
> > On Feb 15, 1:19 pm, Stan B <[email protected]> wrote:
>
> > > Register applies to service locator which ties an interface to a
> > > concrete class. What is wrong with instantiating a repository in a
> > > view and passing it interface to presenter in constructor? In this way
> > > I can unit test presenter easily.
>
> > > On Feb 13, 6:51 am, bill richards <[email protected]>
> > > wrote:
>
> > > > What on earth are you talking about?!?!
>
> > > > Upon what are you calling register if it's not an IoC container? And
> > > > why would you EVER want to instantiate a repository within a view?
>
> > > > On Feb 12, 3:04 pm, Stan B <[email protected]> wrote:
>
> > > > > I guess this is the only way around it... The code came from
> > > > > SharePoint guidance library. There are no IoC container there, the
> > > > > repostitories are instantiated in the prsenters, although they
> > > > > probably should have been in the views..
>
> > > > > On Feb 12, 9:14 am, Patrick Steele <[email protected]> wrote:
>
> > > > > > I would change the implementation so that the Presenter gets an
> > > > > > IProfileRepository in the constructor. During unit testing, just
> > > > > > feed
> > > > > > it your mock. In production, use an IoC container to inject it.
>
> > > > > > ---
> > > > > > Patrick Steelehttp://weblogs.asp.net/psteele
>
> > > > > > On Fri, Feb 12, 2010 at 8:55 AM, Stan B <[email protected]> wrote:
> > > > > > > Oh, I see, thank you. I need Activator.Create instance in order
> > > > > > > to
> > > > > > > swap real repository (class that talks to SharePoint) to the mock
> > > > > > > during unit testing. I am testing presenter class that doesn't
> > > > > > > see the
> > > > > > > difference because it is where Activator.CreateInstance for the
> > > > > > > given
> > > > > > > interface is called and real or mock type is being instantiated.
>
> > > > > > > I can accomplish this by creating manual (static) class mock but
> > > > > > > don't
> > > > > > > want to go to this route..
>
> > > > > > > On Feb 12, 8:21 am, Patrick Steele <[email protected]>
> > > > > > > wrote:
> > > > > > >> On Fri, Feb 12, 2010 at 7:52 AM, Stan B <[email protected]>
> > > > > > >> wrote:
> > > > > > >> > Here is the problem in a nutshell, only two lines of code:
>
> > > > > > >> > IProfileRepository mock =
> > > > > > >> > mocks.StrictMock<IProfileRepository>();
>
> > > > > > >> > Activator.CreateInstance(mock.GetType()); // this fails with
> > > > > > >> > "No
> > > > > > >> > parameterless constructor defined for this
> > > > > > >> > object"
>
> > > > > > >> > Why doesn't mock have default constructor?
>
> > > > > > >> Because you're not supposed to "create" direct instances of
> > > > > > >> mocks.
> > > > > > >> Rhino Mocks creates the mock object for you and handles all of
> > > > > > >> internal plumbing to keep track of expectations and stubbing.
>
> > > > > > >> Your first line of code (IProfileRepository mock =
> > > > > > >> mocks.StrictMock<IProfileRepository>()) tells Rhino Mocks to
> > > > > > >> generate
> > > > > > >> (dynamically) an object that implements the IProfileRepository
> > > > > > >> interface. So what you're given back ("mock") is an object that
> > > > > > >> was
> > > > > > >> dynamically created from Rhino Mocks, but it implements your
> > > > > > >> interface
> > > > > > >> and can therefore be used in place of your real
> > > > > > >> ProfileRepository.
>
> > > > > > >> What are you trying to accomplish with the
> > > > > > >> Activator.CreateInstance?
>
> > > > > > >> ---
> > > > > > >> Patrick Steelehttp://weblogs.asp.net/psteele
>
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the
> > > > > > > Google Groups "Rhino.Mocks" 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
> > > > > > > athttp://groups.google.com/group/rhinomocks?hl=en.-Hidequotedtext-
>
> > > > > > - Show quoted text -- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" 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/rhinomocks?hl=en.
