1

I have inherited a badly architected and organised ASP.NET MVC application, which is an online booking system for healthcare providers. It seems to have been designed with very few object oriented principles used at all, and little abstraction or SoC. So, I am rewriting a lot of the backend code.

I have implemented Entity Framework 6 to replace the current direct database calls that populate DataTables that get returned by static method calls. I have created a Business Logic Layer (BLL) and a Data Access Layer (DAL) (in folders/namespaces in the same project, not as class libraries). I keep the database entity classes in the Models folder.

I am rewriting my Controllers as "thin" controllers that take application data, transform it if necessary and create BLL objects which perform all of the actions needed. The controller then manipulates the returned data into views etc.

Where should helper classes/methods be that manipulate the BLL object data for views?

For example: I have a BookableTreatments BLL class that contains all bookable treatments. The view requires an HTML Select element with an option for each treatment that a specific provider offers. So I might create a helper class SelectListGenerator that has a method that takes a BookableTreatments object and a ProviderID and returns an IList that can be used to generate the HTML select.

Where should my SelectListGenerator class be located? It isn't a controller, it isn't business logic as it is application specific. Should I create a new namespace and folder called ALL (abbreviation for Application Layer Logic, not the word "all") that contains just classes for this sort of purpose? I don't expect to have huge numbers of classes like this.

(Please note, I do have a BookableProviders class that contains provider information, and I could have this class contain a list of treatments that the provider offers. So, I understand it may be better to do this and not have a list of treatments I need to filter for a specific provider, but that's an unrelated issue. And even if that is the case, I would still need to generate a select list for the view. So, the question still stands in its generic form)

Thank you!

Improve this question
7
  • Do you use your database entity classes directly in your views?
    – Greg Burghardt
    Apr 7, 2022 at 13:43
  • Do your controllers accept database entity classes as method arguments in POSTs back to the server?
    – Greg Burghardt
    Apr 7, 2022 at 13:44
  • Hi Greg. My controllers have routes that take primitive query string values and usually return JSON formatted results to the client (web browser). The database entity classes are only used in BLL classes
    – Kyohei Kaneko
    Apr 7, 2022 at 13:49
  • Some routes return Views and others are called in Ajax requests and return JSON
    – Kyohei Kaneko
    Apr 7, 2022 at 13:52
  • I would characterize an architecture using BLL/DAL/Layers/"Entities"/Helper classes/methods also as "designed with very few object oriented principles". So.... are you sure the previous design is bad or is it just different? Just making sure :)
    – Robert Bräutigam
    Apr 7, 2022 at 14:12

2 Answers 2

Reset to default
2

There is no "proper" place for helper classes in the ASP.NET MVC framework. I've created a folder named "Helpers" in projects that use this framework, and that seems to work fine. There is no right way or best practice, because the MVC design pattern doesn't provide guidance, and Microsoft (the vendor for the framework) doesn't have any recommendations either.

This question illuminates my biggest criticisms of MVC web frameworks that have folders named "models", "views" and "controllers". Microsoft's ASP.NET MVC framework is not the only offender. Arguably the framework committing this sin originally was the Ruby on Rails MVC framework for Ruby.

Folders named models, views and controllers make people think every file and class must be categorized as a model, view or controller. Don't confuse the Model-View-Controller Design Pattern with application architecture.

The MVC pattern is a user interface design pattern. It does not describe each layer or area of your application architecture. How you organize business logic, authorization, authentication, data access and even user input validation is not covered by the MVC pattern. Beyond models, views and controllers, code organization is up to you and your team. Do what makes sense.

Improve this answer
6
  • Thanks, this is the approach I came around to whilst waiting for your response. I don't particularly like the MVC framework myself, but I didn't want to have to rewrite the entire application from scratch.
    – Kyohei Kaneko
    Apr 7, 2022 at 14:51
  • 1
    @KyoheiKaneko: the framework would be a lot nicer to work with if it allowed you to organize code by feature by default, rather than models, views or controllers. That would make questions like this irrelevant. Group classes together by feature. But that's not how they designed the framework.
    – Greg Burghardt
    Apr 7, 2022 at 14:59
  • 1
    @GregBurghardt: I agree 100% to your former comment organizing code by feature leads to way more maintainable and evolvable systems. However, since each program or application system provides usually very different features, I think it is pretty hard to come up with a generalized framework for such an architecture, at least a framework which would be useful for many different applications.
    – Doc Brown
    Apr 7, 2022 at 15:24
  • Folders named models, views and controllers make people think every file and class must be categorized as a model, view or controller. -- If it's not a View or a Controller, it's a Model class by default. The Model portion of MVC is basically "anything that is not a View or a Controller." People get confused about this because they think MVC is an application architecture, but it's actually a UI architecture.
    – Robert Harvey
    Apr 9, 2022 at 0:15
  • Anyway, folders are not the issue anyway; namespaces and file names are more important than the folder structure. Larger MVC projects are generally better served by grouping folders (and namespaces) by module, sub-domain, department or aggregate root, not by models, views and controllers (except perhaps as sub-groupings of a module, subdomain, department or aggregate root).
    – Robert Harvey
    Apr 9, 2022 at 0:18
0

If I were dealing with an online booking system in ASP.NET I would evaluate to what extent it makes sense to modernize to a services / microservices, or serverless approach. Try a few small experiments and see what works. An online booking system sounds like a candidate for serverless, but the refactoring / rewriting may be too extensive.

There are guides everywhere on the internet for breaking apart monoliths. Since you are in ASP.NET I would start with Microsoft how to migrate my monolithic ASP.NET codebase - https://docs.microsoft.com/en-us/dotnet/architecture/modernize-with-azure-containers/ and https://devblogs.microsoft.com/premier-developer/moving-your-asp-net-applications-to-the-microsoft-cloud/

Maybe a hybrid approach? Leave the current mess as-is, and new work is encapsulated and part of a new cloud native architecture?

What problems are you facing that would lead you to refactor? Difficulty scaling? Challenges operating in cloud environments? Inability to rapidly deploy updates to customers? Maintenance costs? General sadness having to work on this code? Does the business appreciate these factors and will they invest in a better architecture?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.