The idea for this post was a question from my colleague, from yesterday, when I was presenting the architecture of the solution for their project: What is the difference between code implementation in code behind, why putting the code in the controller class, why it is not in the business layer?
The answer to this question is simple, MVC pattern: model - view - controller.
Little explanation on this:
View is the graphical data presentation (outputting) irrespective of the real data processing. View is the responsible for look and feel, some custom formatting, sorting etc. View is completely isolated from actual complex data operations.
Model is responsible for actual data processing, like database connection, querying database, implementing business rules etc. It feeds data to the view without worrying about the actual formatting and look and feel.
Controller is responsible for Notice of action. Controller responds to the mouse or keyboard input to command model and view to change. Controllers are associated with views.
Some benefits:
- Since the Model is completely decoupled from view it allows lot of flexibility to design and implement the model considering reusability and modularity
- It is possible to have development process in parallel for model, view and controller
- This makes the application extensible and scalable
My comments on this issue: there must be a clear and obvious separation of responsibilities, code-behind is view code, never controller/presenter. If you place controller responsibility into the code-behind, good luck with testing. Your lack of cohesion goes up, tight-coupling goes up, extensibility drops and testability drops.
I was trying to explain this, but like always..."please show us code, if you want us to understand.... "
Regular code in their application looks like this: (the code should check if the current product exists in the order, and read all business rules for that product: discount depending on ordered quantity, delivery period for the order depending on the value of the order...)
protected void btnAddProduct_Click(object sender, EventArgs e)
{
foreach (Product pr in productList)
{
if (pr.ProductId == selectedProduct)
{
// Add quantity
pr.Quantity +=1;
// Apply discount rule
// if pr.Quantity >2 then pr.Discount=5; if prQuantity > 5 then pr.Discount=10
// Apply order delivery date rule
// if order.Amount > 1000$ then order.DeliveryDate = order.StartDate + 3 days
}
}
}
Very bad thing to do....
Instead of this, try to transfer your code in the controller class, let her communicate with all business rules, and with the data access.
public static void CheckProduct(Product currentProduct)
{
CheckProduct(currentProduct);
SetOrderDelivery();
} private void CheckProduct(Product pr)
{
// CheckProduct existance
// Call Product Business logic
// ProductBL.SetDiscount(pr)
}
private void SetOrderDelivery()
{
// Calculate order amount
// Call Order Business logic
// OrderBL.SetDeliveryDate(currentOrder)
}
... finally, call the public method from code-behind:
find appropriate place in your code-behind for creating an instance of the controller...
OrderProcessControler opc = new OrderProcessControler();
...and use it in your event handlers protected void btnAddProduct_Click(object sender, EventArgs e)
{
opc.CheckProduct(selectedProduct);
}
Note: The controller methods must be placed in different project (class library) for easier scalability of the solution.
Those methods can be modified at any time, deployed separately from the presentation logic.