I will try to provide you some recommendations.
Suppose you have an existing WCF service defined like this (we don’t care about an implementation that is not important at the moment, you can implement it on your own, varying from hard-coded values, going through the SQL and ORM database, for using another service in the cloud):
[DataContract] public class Product { [DataMember] public int Id { get; set; } [DataMember] public string Name { get; set; } } [ServiceContract] public interface IProductsService { [OperationContract] Product Get(int id); }
Now in your ASP.NET MVC application, the first step is to add a service reference, pointing to the WSDL. This will create proxy client classes.
You can then add the Unity.Mvc3 NuGet package to your MVC application.
Then in your Application_Start you can configure the container (obviously, this configuration could be externalized in a separate method to avoid cluttering your Global.asax with it):
protected void Application_Start() { AreaRegistration.RegisterAllAreas(); RegisterGlobalFilters(GlobalFilters.Filters); RegisterRoutes(RouteTable.Routes); var container = new UnityContainer(); container .RegisterType<IProductsService, ProductsServiceClient>() .Configure<InjectedMembers>() .ConfigureInjectionFor<ProductsServiceClient>(new InjectionConstructor("*")); DependencyResolver.SetResolver(new UnityDependencyResolver(container)); }
IProductsService and ProducsServiceClient used in this configuration are proxy classes generated when importing the web service definition.
From now on, things become trivial:
public class HomeController : Controller { private readonly IProductsService _productsService; public HomeController(IProductsService productsService) { _productsService = productsService; } public ActionResult Index() { var product = _productsService.Get(1); return View(product); } }
and some corresponding index index:
@model Product <div> @Html.DisplayFor(x => x.Name) </div>
As you can see from this example, thanks to the abstraction of IProductsService , the HomeController is completely separate from any specific service implementation. In Today, in your Global.asax, you decide to use WCF (ProductServiceClient), but tomorrow you may decide to use a completely different implementation. With one change in the configuration of the DI container, you can switch the implementation. Thanks to this loose connection, your controllers are fully tested separately.
It’s important to understand that your business is the Product class and the IProductsService interface. This is what your domain reflects. This is M in MVC. Implementations may change, but this should remain unchanged, otherwise you have incorrectly defined your business requirements, which can be catastrophic in the long run.
Note: one thing that I did not consider in this example, and which is very important, is the use of view models. In a properly designed ASP.NET MVC application, you should never pass domain models to your views (in this example, the Product class). You must use view models. View models are classes specifically designed for this type of requirement. Thus, in a real ASP.NET MVC application, you will have the ProductViewModel class for which the product model will be displayed in the controller action, and this ProductViewModel will be passed to the view. These view models must be defined in the MVC project, because, contrary to your domain models, they cannot be reused and reflect only the specific requirements for a single view. To simplify the mapping between your domain models and view models, you can take a look at AutoMapper .