How to implement layers for a Windows Service
Hi I am busy updating an existing Windows Service that had all business objects and data access code inside a single class.
I have created a new Data Access Layer and moved all data related access code to it. Next, I created a Business Object Layer for all Business objects.
At this point I am not a 100% sure whether I need to access my Data Access Layer from inside my Windows Service or do I need to implement something additional? I examined your Patterns-In-Action example and I assume the implementation of the Service layer is WCF related. Thank you, Fred
Fred Mare, Feb 08, 2011
I'm not sure if I understand the question, but:
Your service does not need to talk to the DAL, it will need to talk to a BL object and that BL object will need to talk to the DAL object.
If you want to keep your code 100% 'pure' then each of your layers (BL, DAL) should be not be dependent on any concrete implementations in another layer. E.g. your BL class should not contain
TaskBusinessLayerObject blObj= new TaskBusinessLayerObject ();
You will, of course, need your BL to communicate with the DAL, but you should be 'program' against interfaces (think an agreed contract) not concrete objects. So, using Dependency Injection (for e.g.), your BL code should read:
ITaskBusinessLayerObject blObj= MyDIContainerOfChoice.Resolve<ITaskBusinessLayerObject>();
In this way, you have no dependency on what the actual implementation of ITaskBusinessLayerObject is. You know that it implements the interface, and therefore is bound to offer the methods and properties defined in the interface (agreed contract)
So, your service will call IBusinessObject busObj = MyDIContainerofChoice.Resolve<IBusinessObject>()
and your business object will call IRepository repObj = MyDIContainerofChoice.Resolve<IRepository>()
Usually, the DI container will read your .config to determine which concrete object should be returned from the Resolve<> call
That said, design purity is a very subjective matter. If you are building an enterprise level application with a long lifespan (that will undergo several changes) this is the way to go. If you are building a personal project to remind yourself to feed the dog, then its overkill since the cost outweighs the benefit.... :)
Greg Stevenson, Feb 09, 2011
Hi Dan, I assumed that since cart is a generic concept that can be used in multiple apps, it has been put into framework. In my opinion the framework consists of mostly agnostic modules that can be either used in other apps or can be replaced with a similar controls. Can you please provide some guidelines on what to put into Framework Vs . what to put into Business layer? Regards Sanjay
Sep 27, 2010