MVC helper functions business logic

Question

I am creating some helper functions (mvc.net) for creating common controls that I need in almost every project such as alert boxes, dialogs etc.

If these do not contain any business logic and it's just client side code (html, js) then it's ok. My problem arises when I need some business logic behind this helper.

I want to create a 'rate my (web) application' control that will be visible every 3 days and the user may hide it for now, navigate to rate link or hide it for ever.

To do this I need some sort of database access and a code that acts as business logic. Normally I would use a controller for this, with my DI and everything, but I don't know where to put this code now.

This should be placed in the helper function or in a controller that responds objects instead of ActionResults?

Answer 1

As the business logic for these helper components will likely differ from project to project, I would split those helpers into two parts:

• One part that must be implemented by each project separately and that provides answers to business-logic questions like: "should I show this control".
• A second, reusable, part that does not contain any actual business logic, but depends on the first part to provide the answers.

The part providing the business logic for the helper component should probably live in the project's Model part, and the project's Controller would be responsible for hooking up the helper with its business logic.

• Menelaos Vergis: In this specific example the project variations may come from settings and parameters. I want every project have the same business logic depending on some parameters. In this case when the code is absolutely the same what would you do?
• Bart van Ingen Schenau: @MenelaosVergis: I would still keep the split. Are you sure that the business logic and underlying data access is identical (down to using the same properties/columns)? In my view, business rules are the second fastest to change (after the UI).