I'm playing around with the Ninject Interception extension. Ian Davis's blog post about it indicates that interception is always based on the actual service type, rather than the interface. For example, the following code will have no effect because IFoo is an interface:
Kernel.InterceptBefore<IFoo>(f => f.DoSomething(),
i => Console.WriteLine("before"));
And of course, the next code piece will only work if Foo.DoSomething is virtual:
Kernel.InterceptBefore<Foo>(f => f.DoSomething(),
i => Console.WriteLine("before"));
This seems like a pretty glaring hole when it comes to Aspect-Oriented programming. I've been pretty conscientious about programming to interfaces so that we could use mocking frameworks to mock our various services, but the vast majority of my actual method implementations are not virtual. If a mocking framework can produce an IFoo with a method that does what I ask for, it seems like Ninject ought to be able to.
So I guess my question is two-fold:
Is there any reason Ninject Interception doesn't allow you to bind to interface methods?
Is there an easy way to make Ninject bind to dynamic "wrapper" classes that can let me perform certain interception actions on all the interface methods, and then pass the call through to the real implementation?
I did some spiking on this and it seems that it is possible to get that behavior into the interception extension. But as we planned to do the 2.2 release in the very near future you have to be a little patient. I defenately like the change so I planned to add it to 2.4. Also the spike is far from productive. All current unit test are running though. But there are a lot of new ones that need to be added with this feature. If you like I can send you a patch but I won't give you any support and guaranties that it is bug free at the moment.
Related
I'm writing a client for a REST API for an ERP system(large complicated piece of software). I want to get the design architecture correct now, so I save myself time down the road, hoping you can help. If helpful server side urls are of the format /myServer/v1/someService/someMethod?someParam=x
I started off with a restClient class with public function for all the ERP actions(e.g. restClient->someServiceSomeMethod(someParam)). The restClient knows about authentication, and has private get, post, etc methods. I started with this approach as it's the simplest architecture, although I'm wondering if I should be using inheritance or some other approach(I don't want to overcomplicate but I'm starting to feel like I'm going down the wrong path). For the past 10 years are so I've written mostly procedural code, so I'm a bit rusty on OOP design... Would it be "better" to have classes for each service that inherits the restClient class? The the end code would then instantiate the service object they need then calls the method(someService->someMethod(someParam)? This "feels" like the right way to go, but I'm fuzzy on how I'd authenticate and it's been a long time since I did OOP so would hate to overcomplicate things and get no value out of it.
A good rule of thumb for me is that simpler is usually better.
Inheritance, in my opinion, feels a bit restrictive for this - and you introduce coupling that might cause you pain later. If you build 100 different services and they all share a common super class, but it turns out that 5 of them need to be behave in a slightly different fashion, everything else will also be affected. That could get messy.
Although I don't have sufficient detail to understand all the aspects of your particular scenario, I would strongly consider composition over inheritance - build a RestClient class that can deal with some of the common scenarios (auth, GET, POST, etc.), but instead of extending it, just provide a reference to it to anything else that might require that functionality.
In addition, if there are various 'groups' of common operations (e.g CRUD), why not model those with an interface? Your classes could then implement the interface instead of extending a common super class, giving you the benefit of consistency but without the drawbacks of inheritance.
I'm not so much seeking a specific implementation but trying to figure out the proper terms for what I'm trying to do so I can properly research the topic.
I have a bunch of interfaces and those interfaces are implemented by controllers, repositories, services and whatnot. Somewhere in the start up process of the application we're using the Castle.MicroKernel.Registration.Component class to register the classes to use for a particular interface. For instance:
Component.For<IPaginationService>().ImplementedBy<PaginationService>().LifeStyle.Transient
Recently I became interested in creating an audit trail of every class and method call. There's a few hundred of these classes so writing a proxy class for each one by hand isn't very practical. I could use a template to generate the code but I'd rather not blow up our code base with all that.
So I'm curious if there's some kind of on the fly solution. I know nHibernate creates proxy classes at some point which overlay all the entity classes. Can someone give me some guidance on how I might be able to do something similar here?
Something like:
Component.For<IPaginationService>().ImplementedBy<ProxyFor<PaginationService>>().LifeStyle.Transient
Obviously that won't work because I can only use generics to generalize the types of methods but not the methods themselves. Is there some tricky reflection approach I can use to do this?
You are looking for what Castle Windsor calls interceptors. It's an aspect-oriented way to tackle cross-cutting concerns -- auditing is certainly one of them. See documentation, or an article about the approach:
Aspect oriented programming is an approach that effectively “injects” pieces of code before or after an existing operation. This works by defining an Inteceptor wrapping the logic being invoked then registering it to run whenever a particular set/sub-set of methods are called.
If you want to apply it to many registered services, read more about interceptor selection mechanisms: IModelInterceptorsSelector helps there.
Using PostSharp, things like this can be even done at compile time. This can speed the resulting application, but when used correctly, interceptors are not slow.
Many times, I've seen single class (Java) implement a single interface. That interface is only used for the single class. No other class implements it. Why do we do this? It seems like to me, we don't need the interface, just the class.
Example: https://github.com/essentials/Essentials/blob/2.x/Essentials/src/com/earth2me/essentials/I18n.java
Forget about the language for a sec.
There are many reasons to use interfaces and having just one class implement an interface is absolutely fine.
Imagine you want to write testable code, you want to do all the good stuff, have tests etc.
A good way to write code is to never ever hard-code any dependencies in a class. It makes life a lot easier if you inject dependencies and that is done via an interface or abstract class. So you basically never say hey class, here's a cat implementation, you say hey here's a generic animal, use that.
The interface has that one job to provide a contract and that's what you are using. You are thus decoupling your code from dependencies, so now you're able to test it and you can mock all your dependencies easily. The fact that you have one or more implementation makes no difference whatsoever.
It was recommended to me that, when using an IOC container, I should change this:
class Foobar: IFoobar, IDisposable {};
Into this:
interface IFoobar: IDisposable{};
class Foobar : IFoobar{};
I'm wondering if this is ok, or if it solves one problem and creates another. It certainly solves the problem where I badly want to do this:
using( IFoobar = myContainer.Resolve<IFoobar>() )
{ ... }
And now I know that any substitute won't cause a run-time error.
On the other hand, now all my mock objects must handle IDisposable too. Am I right that most any mocking framework handles this easily? If yes, then perhaps this is a non-issue.
Or is it? Is there another hidden gotcha I should watch for? It certainly occurs to me that if I were using an IOC container not for unit tests / mocking, but for true service independence, then this might be a problem because perhaps only one of my swappable services actually deals with unmanaged resources (and now I'm having to implement empty "IDispose" operations in these other services).
Even this latter issue I suppose I could live with, for the sake of gaining the ability to employ the "using" statement as I demoed above. But am I following a popular convention, or am I missing an entirely different and better solution?
Deriving an interface from IDisposable is in my opinion a design smell that indicates a Leaky Abstraction. As Nicholas Blumhardt put it:
an interface [...] generally shouldn't be disposable. There's no way for the one defining an interface to foresee all possible implementations of it - you can always come up with a disposable implementation of practically any interface.
Consider why you want to add IDisposable to your interface. It's probably because you have a particular implementation in mind. Hence, the implementation leaks into the abstraction.
An DI Container worth its salt should know when it creates an instance of a disposable type. When you subsequently ask the container to release an object graph, it should automatically dispose the disposable components (if their time is up according to their lifestyles).
I know that at least Castle Windsor and Autofac does this.
So in your case, you should keep your type like this:
class Foobar: IFoobar, IDisposable {};
You may find Nicholas Blumhardt's post The Relationship Zoo interesting as well - particularly the discussion about Owned<T>.
Many people use Mock Objects when they are writing unit tests. What is a Mock Object? Why would I ever need one? Do I need a Mock Object Framework?
Object Mocking is used to keep dependencies out of your unit test.
Sometimes you'll have a test like "SelectPerson" which will select a person from the database and return a Person object.
To do this, you would normally need a dependency on the database, however with object mocking you can simulate the interaction with the database with a mock framework, so it might return a dataset which looks like one returned from the database and you can then test your code to ensure that it handles translating a dataset to a person object, rather than using it to test that a connection to the database exists.
Several people have already answered the 'what', but here are a couple of quick 'whys' that I can think of:
Performance
Because unit tests should be fast, testing a component that
interacts with a network, a database, or other time-intensive
resource does not need to pay the penalty if it's done using mock
objects. The savings add up quickly.
Collaboration
If you are writing a nicely encapsulated piece of
code that needs to interact with someone else's code (that hasn't
been written yet, or is in being developed in parallel - a common
scenario), you can exercise your code with mock objects once an
interface has been agreed upon. Otherwise your code may not begin to
be tested until the other component is finished.
A mock object lets you test against just what you are writing, and abstract details such as accessing a resource (disk, a network service, etc). The mock then lets you pretend to be that external resource, or class or whatever.
You don't really need a mock object framework, just extend the class of the functionality you don't want to worry about in your test and make sure the class you are testing can use your mock instead of the real thing (pass it in via a constructor or setter or something.
Practice will show when mocks are helpful and when they aren't.
EDIT: Mocking resources is especially important so you don't have to rely on them to exist during the test, and you can mock the details of how they exist and what they respond (such as simulating a FileNotFoundException, or a webservice that is missing, or various possible return values of a webservice)... all without the slow access times involved (mocking will prove MUCH faster than accessing such resources in the test).
Do I need a Mock Object Framework?
Certainly not. Sometimes, writing mocks by hand can be quite tedious. But for simple things, it's not bad at all. Applying the principle of Last Responsible Moment to mocking frameworks, you should only switch from hand-written mocks to a framework when you've proven to yourself that hand-writing mocks is more trouble than it's worth.
If you're just getting starting with mocking, jumping straight into a framework is going to at least double your learning curve (can you double a curve?). Mocking frameworks will make much more sense when you've spent a few projects writing mocks by hand.
Object Mocking is a way to create a "virtual" or mocked object from an interface, abstract class, or class with virtual methods. It allows you to sort of wrap one of these in your own definition for testing purposes. It is useful for making an object that is relied on for a certain code block your are testing.
A popular one that I like to use is called Moq, but there are many others like RhinoMock and numerous ones that I don't know about.
It allows you to test how one part of your project interacts with the rest, without building the entire thing and potentially missing a vital part.
EDIT: Great example from wikipedia: It allows you to test out code beforehand, like a car designer uses a crash test dummy to test the behavior of a car during an accident.
Another use is it will let you test against other parts of your system that aren't built yet. For example, if your class depends on some other class that is part of a feature that someone else is working on, you can just ask for a mostly complete interface, program to the interface and just mock the details as you expect them to work. Then, make sure your assumptions about the interface were correct (either while you are developing, or once the feature is complete).
Whether or not you a mocking framework is useful depends in part on the language of the code you're writing. With a static language, you need to put in extra effort in order to trick the compiler into accepting your mock objects as a replacement for the real thing. In a dynamically-typed language such as Python, Ruby or Javascript, you can generally just attach the methods onto arbitrary object or class and pass that as the parameter -- so a framework would add much less value.
2 recommended mocking frameworks for .net Unit testing are Typemock Isolator and Rhino Mock.
In the following link you can see an explanation from Typemock as to why you need a mocking framework for Unit Testing.