I've started using ISerializableCart and want to create our own IShippingPlugin. This is my code (at the moment i'm just returning some mock code):
public class Print : IShippingPlugin
public ShippingRate GetRate(Guid methodId, IShipment shipment, ref string message)
return new ShippingRate(methodId, "Print", new Money(110, new Currency("NOK")));
return new ShippingRate(methodId, "Print", new Money(0, new Currency("NOK")));
However i keep getting this error when i try to run the ICart GetTotal():
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.MissingMethodException: Constructor on type 'xx.Print' not found.
I've tried to add an empty constructor to my code but i still get the error.
Anyone know what's wrong here?
You'll have to have a constructor which takes an IMarket as parameter.
public Print(IMarket market)
I'll check to see if the documentation needs to be updated to reflect that.
That worked. Thanks!
Very strange thing to demand from an implementation. Whatever instantiates these should support empty constructors too; It's an implementation detail whether or not a shipping plugin requires the market it belongs to or is used in.
An interface defines the functionality the calling application wants, it should not care exactly how this happens - that's where IOC containers come into play. StructureMap can figure out what the implementation needs based on the constructors it has. Episerver itself should not put any restrictions onto this. What if one wants more input via constructor injections, but none of them are of IMarket implementations?
That's good point Arve. I have some ideas to improve APIs, but that needs to be discussed within our team first.
As with most other things, using Activator.CreateInstance should be avoided when one has an IOC container like StructureMap. If one always calls that and makes sure it gets objects, consuming parties can require whatever they want. It should very often make for a far simpler implementation in calling classes, and a less confusing way of implementing the interfaces. :-)