0

I'm currently developing business logic in a Controller's ActionResult function, and I've noticed it's becoming unwieldy... large... involves a lot of page ups/downs.

Code includes populating lists for dropdownlists assigned to ViewBag properties, but most of the size is taken up EF (linq to entities) and in memory processing of this. And finally sent to a view model via Auto Mapper.

Where is the best place to move this code? In another class in the Controllers folder? Or in another class in another folder, i.e. a Business layer?

OpcodePete
  • 887
  • 1
  • 14
  • 28
  • 1
    As far as I understood, you don't have a data access layer. If you had, you could move all your data processing code to that layer, hereby relieving your controller. – anar khalilov Jan 23 '14 at 07:44
  • I have Models and View models, and have always taken this to mean I have a Data Access Layer (DAL). But if a DAL is meant to includes business logic then you are correct, I do not have a DAL. If so, can you/anyone point me to a DAL best practice? Thanks. – OpcodePete Jan 23 '14 at 07:52
  • 1
    If you have a DAL, then I think it is a good idea to move your code that "includes populating lists for dropdownlists assigned to ViewBag properties, but most of the size is taken up EF (linq to entities)" to there. – anar khalilov Jan 23 '14 at 07:59
  • All great answers here!!! Each post answered my question. It was difficult to decide. – OpcodePete Jan 23 '14 at 22:00

4 Answers4

4

Separate you project to :

  • WebUI(View, Controller-A MVC Project)
  • Business Layer(Holds Business Logic - A class Library Project )
  • Data Access Layer(Holds Entity Model(May be EDMX) - A class Library Project)

A controller of WebUI project call method of business layer. If business need data from database then, it will call Data Access Layer.

Bappi Datta
  • 1,360
  • 8
  • 14
1

Funnily enough I answered a very similar question yesterday. In a nutshell, limit your controller to just the minimum logic to link your models with your views. Business logic, data access etc. is better placed in a separate repository.

Community
  • 1
  • 1
Simon
  • 6,062
  • 13
  • 60
  • 97
1

Bappi Datta is right. Let me just explain it from my point of view.

My best practice with the libs AutoMapper, EF is:

  • Web - includes logic of rendering, some validation, bootstrap configuration. Calls Business layer methods and classes.
  • Web.Models - web models with validation attributes
  • BusinessLogic - business layer. Includes mappings EF Entities <---> Web.Models. Uses Data classes.
  • Data - Here I always put EF Models and context. Also implementation of Repository pattern could be placed there.
Andrei
  • 42,814
  • 35
  • 154
  • 218
1

You need to have Repository Layer (which you mentioned you already have) and then you need to have a Service Layer which will hold all your necessary business logic probably using patterns like Command Factory and Facades. Then in order for you to have a flexible and easily pluggable architecture, you need to use Dependency Injection between all layers.

Read about MVC architecture in my perspective

There can be different If's and But's in the theoretical discussion of overall MVC architecture itself. But generally your controller actions needs to be thin, you business logic needs to be in a different layer other than repository.

enter image description here

ramiramilu
  • 17,044
  • 6
  • 49
  • 66
  • Dependency Injection... I will have to look into this and implement when the Service layer is completed. Thank you, I had heard of this, but never looked into it. And great site intstrings! – OpcodePete Jan 23 '14 at 22:06