I have been doing laravel since 4 months. I don't find a clear difference between facades and contracts as they both are set of interfaces. Why would i use facades instead of contracts or contracts instead of facades?
The question whether to use Facade or Contract boils down how you want to resolve your classes and if you want to use interfaces.
Facade
A facade is a class and not an interface (here is an example facade).
A facade is only used to load a class from service container more convenient
The class that is going to be loaded is determent in the getFacadeAccessor() method of the facade class.
Example:
// Without facade - resolving from service container
app('some_service')->methodName();
// Do the same through facade:
someService::methodName();
Contract
A contract is an interface (here is an example)
A contract is used to load a class from service container more convenient AND as an interface
The class that is going to be loaded is determined in the service container, see Binding Interfaces To Implementations
Example: Assuming that class some_service implements interface Illuminate\Contracts\Config\Repository:
// resolving class directly from service container
app('some_service')->methodName();
// resolve through binding from contract
app('Illuminate\Contracts\Config\Repository')->methodName();
Related
I am new to WCF; I have an abstract class that in my WCF service.
I am referencing that WCF service from another application that invokes it: I have it added as a Service Reference in my Visual Studio project.
I managed to serialize the derived classes using the ServiceKnownType attribute, but I cannot manage to make the base class automatically abstract in the service reference code.
Any ideas?
I'm not sure whether this is something that will work in your case, but you can't (with the normal Add Service Reference tool) directly generate abstract classes.
However, all generated classes are partial, so if you know the namespace, all that's required to make it abstract is a new file with;
namespace whatever.the.service.reference.namespace.is {
abstract partial class MyClass { }
}
...and the class will be marked abstract.
We are implementing IoC/DI in our application using NInject framework. We are having internal classes having internal methods. To implement IoC/DI, we have to extract interfaces. But if we are having only internal methods in an internal class, we can't extract interface for that class.
So is there a way to implement IoC/DI in such cases (internal class having only internal methods) or should we change our internal methods to public methods. Kindly suggest. Thanks
If your class is already internal then there is absolutely not difference between internal and public methods. public methods of internal classes are only internally visible.
If you stay with injecting concrete classes though you loose all the advantages of DI. So yes you should extract (internal) interfaces and inject the interfaces. This requires that the configuration code has access to the classes by either beeing in the same assembly of the assembly must be declased as friend assembly. Futhermore, you have to configure Ninject to allow none public classes. See NinjectSettings.
The only thing that you really need to make public is the interface (not the concrete implementation).
You can use an abstract factory or (easier) Ninject to map the public interface to the internal concrete; thus your client code just has to request an instance of "a thing" that implements the interface and your factory / container will return the implementation.
You should read up on Dependency Inversion Principle as well as it goes hand-in-hand with this.
You could use InternalsVisibleTo attribute in AssemblyInfo.cs file like this
[assembly: InternalsVisibleTo("Assembly_That_Should_Access_The_Internal_Class")]
I want to mock a ServiceContract. The problem is that Moq (and Castle Dynamic-Proxy) copies the attributes from the interface to the dynamic proxy which Wcf don't like. Wcf says: The ServiceContractAttribute should only be define on either the interface or the implementation, not both.
Exception is: InvalidOperationException - The service class of type Castle.Proxies.IWorkOrderRequestServiceProxy both defines a ServiceContract and inherits a ServiceContract from type IWorkOrderRequestService. Contract inheritance can only be used among interface types. If a class is marked with ServiceContractAttribute, it must be the only type in the hierarchy with ServiceContractAttribute. Consider moving the ServiceContractAttribute on type IWorkOrderRequestService to a separate interface that type IWorkOrderRequestService implements
Just experienced the same problem - so +1 for a solution! :-)
Update: http://code.google.com/p/moq/source/browse/trunk/Source/Proxy/CastleProxyFactory.cs contains a reference to a property (collection) called AttributesToAvoidReplicating, looks like a place to start looking in the Moq source code.
Update #2: Nailed it!
Add:
Castle.DynamicProxy.Generators.AttributesToAvoidReplicating.Add(typeof(ServiceContractAttribute));
before you wire up anything in your kernel.
I have an interface ICustomerService:
public interface ICustomerService
{
CustomerList FindAll();
}
and a concrete class implementing that interface. Now I need to expose the method over the web using wcf/rest and I've had to change the interface definition to this:
[ServiceContract]
public interface ICustomerService
{
[OperationContract]
[WebInvoke(
Method = "GET",
UriTemplate = "Customers")]
CustomerList FindAll();
}
My question is if there is any downside to having these attributes attached to your interface if there are clients that want to use the implementation using dll reference instead of using the rest api? I am aware of the shortcomings in using REST like having to have your parameters as type string if its in the uri.
There should be no downsides of the attributes except maybe in code readability (if your clients have to look at your interface source).
The attributes can be read by anyone interested (like the WCF framework) or will be ignored. Actually they won't be visible from any implementing class (see this question).
At the architecture level however, consider using 2 interfaces, one for the dll-referencing clients and one for the REST clients. They might be similar the begin with, they might even share the same base interface and implementation, but you have the ability to make them divert from each other if the business case requires it.
Also, this gives you the possibility to keep the WCF attribute filled interfaces in the WCF web application project, and the clean interfaces and implementations in a core class library project.
I am just starting out with DI & unit testing and have hit a snag which I am sure is a no brainer for those more experienced devs :
I have a class called MessageManager which receives data and saves it to a db. Within the same assembly (project in Visual Studio) I have created a repository interface with all the methods needed to access the db.
The concrete implementation of this interface is in a separate assembly called DataAccess.
So DataAccess needs a project reference to MessageManager to know about the repository interface.
And MessageManager needs a project reference to DataAccess so that the client of MessageManager can inject a concrete implementation of the repository interface.
This is of courser not allowed
I could move the interface into the data access assembly but I believe the repository interface is meant to reside in the same assembly as the client that uses it
So what have I done wrong?
You should separate your interface out of either assembly. Putting the interface along with the consumer or the implementor defeats the purpose of having the interface.
The purpose of the interface is to allow you to inject any object that implements that interface, whether or not it's the same assembly that your DataAccess object belongs to. On the other hand you need to allow MessageManager to consume that interface without the need to consume any concrete implementation.
Put your interface in another project, and problem is solved.
You only have two choices: add an assembly to hold the interface or move the interface into the DataAccess assembly. Even if you're developing an architecture where the DataAccess class may someday be replaced by another implementor (even in another assembly) of the repository interface, there's no reason to exclude it from the DataAccess assembly.
Are you using an Inversion of Control Container? If so, the answer is simple.
Assembly A contains:
MessageManager
IRepository
ContainerA (add MessageManager)
Assembly B contains (and ref's AssemblyA):
Repository implements IRepository
ContainerB extends ContainerA (add Repository)
Assembly C (or B) would start the app/ask the container for MessageManager which would know how to resolve MessageManager and the IRepository.
I think you should move the repository interface over to the DataAccess assembly. Then DataAccess has no need to reference MessageManager anymore.
However, it remains hard to say since I know next to nothing about your architecture...
Frequently you can solve circular reference issues by using setter injection instead of constructor injection.
In pseudo-code:
Foo f = new Foo();
Bar b = new Bar();
f.setBar(b);
b.setFoo(f);
Dependency inversion is in play:
High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
The abstraction that the classes in the DatAccess assembly depend upon needs to be in a separate assembly from the DataAccess classes and the concrete implementation of that abstration (MessageManager).
Yes that is more assemblies. Personally that's not a big deal for me. I don't see a big downside in extra assemblies.
You could leave the structure as you currently have it (without the dependency from MessageManager to DataAccess that causes the problem) and then have MessageManager dynamically load the concrete implementation required at runtime using the System.Reflection.Assembly class.