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: 494

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

Related posts about wcf

Related posts about factory