How to implement layers for a Windows Service

Hi Fred,

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 ();
blObj.DoSomething(requiredInfo);

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>();
blObj.DoSomething(requiredInfo);

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.... :)