Question regarding the business layer

[riffrack]

Hi Jon

You mention in your GenericServices milestones, that you removed the Action methods, as to make it all about database access. The business logic should go into a seperate library.

Could you briefly explain how you would recommend structuring the project to use a business layer together with GenericServices?

When I download this app, a root folder BizLayer & a class library exist, but is not included in the solution. Would I add this class library to the solution & input any business processes into there? For example if I have a workflow where the user edits the state of DTO object in the UI, which is persisted in the database, how would you recommend I include this workflow process into the existing solution structure?

Thanks

[JonPSmith]

Hi @riffrack,

I took a little while replying to this because I felt it needed a deeper answer. I have written an article on my blog called Architecture of Business Layer working with Entity Framework. The article pulls together my approach to building and accessing the Business Layer. I hope you find that helpful.

For your example, if you have something that needs to set a state based on some rules then the best place is in the BizLayer. In SampleMvcWebAppComplex SalesOrderHeader have a status and I only used Pending and Shipped. I didn't handle the changing of the status as I didn't want to create a BizLayer just for that.

On your specific questions in SampleMvcWebApp and the BizLayer.

1. Yes, include BizLayer in the project. Its just a class library.
2. The BizLayer will need to access the DataLayer. Use the Reference Manager-> Solution
3. The ServiceLayer, if that is where you add your linking/adpater code, will then need to reference the BizLayer.

[riffrack]

Hi @JonPSmith

Thanks for your detailed response & the great article describing your view on the business layer. In your implementation example, do I understand this correctly? The controller would pass the DTO to the business layer for some form of action. In case there is any persistence needed, the biz layer would interact with the service layer & the service layer would handle the interaction with the data layer. The response (message or class) would then be handed back all the way up to the controller.

As you mention for the SampleMvcWebAppComplex you didn't create a BizLayer for a minor status change. For apps with only very little BizLogic this could all be handled in the ServiceLayer. However in most projects with BizLayer probably will grow during development, as these rule are not always aparent from the start of a project.

Would you therefore initialize the BizLayer during the InitialiseThis method of the ServiceLayerInitialise?

[riffrack]

One reason I am unsure about the exact implementation is that the diagram would suggest the business layer interacts directly with the data layer, however in the description about "The Business Layer does not do the final data save" the business layer would let the service layer do the final save.

[JonPSmith]

Answers:

First para: The BizLayer uses EF to add new database classes, or for updates simple read and then update the data, hence the link to the DataLayer (it is also needed for it to read data). When the Biz logic hands back to the ServiceLayer method that calls SaveChanges and handles any validation errors that are produced.

Second para: Yep, if you only have a small bit of Biz logic I would put it in the Service layer. However because I have my own GenericAction library I would add a BizLayer for even one piece of Biz logic.

Third para: The InitiaiseThis, and BizLayerModule for DI, method is my own way of initialising each layer. See Dependency Injection in Wiki for a bit more on DI initialise.