Factories, or Dependency Injection for object instantiation in WCF, when coding against an interface
Posted
by Saajid Ismail
on Stack Overflow
See other posts from Stack Overflow
or by Saajid Ismail
Published on 2009-08-14T09:02:11Z
Indexed on
2010/03/30
23:13 UTC
Read the original article
Hit count: 512
Hi
I am writing a client/server application, where the client is a Windows Forms app, and the server is a WCF service hosted in a Windows Service. Note that I control both sides of the application.
I am trying to implement the practice of coding against an interface: i.e. I have a Shared assembly which is referenced by the client application. This project contains my WCF ServiceContracts and interfaces which will be exposed to clients. I am trying to only expose interfaces to the clients, so that they are only dependant on a contract, not any specific implementation. One of the reasons for doing this is so that I can have my service implementation, and domain change at any time without having to recompile and redeploy the clients. The interfaces/contracts will in this case not change. I only need to recompile and redeploy my WCF service.
The design issue I am facing now, is: on the client, how do I create new instances of objects, e.g. ICustomer
, if the client doesn't know about the Customer
concrete implementation? I need to create a new customer to be saved to the DB.
Do I use dependency injection, or a Factory class to instantiate new objects, or should I just allow the client to create new instances of concrete implementations?
I am not doing TDD, and I will typically only have one implementation of ICustomer
or any other exposed interface.
© Stack Overflow or respective owner