Où devrais-je mettre ma logique métier contrôleur dans MVC3

Question

Je comprends MVC est tout au sujet de mettre les choses au bon endroit et la logique où il devrait être. Mes actions de contrôleur sont remplies de logique métier (non liée au stockage de données) et je pense que je devrais commencer à déplacer une partie de la logique vers un autre endroit.

Y a-t-il une convention pour où je devrais placer cette logique? Par exemple, j'ai le contrôleur suivant qui est situé dans le fichier contrôleurs:

adminPowerController 

    public ActionResult Create(string test1) 
    // business logic 
    // business logic 
    // business logic 
    return View(); 
    } 
    public ActionResult Index(string test1) 
    // business logic 
    // business logic 
    // business logic 
    return View(); 
    } 

Answer 1

L'endroit recommandé de mettre la logique métier est dans une couche de service. Vous pouvez donc définir une interface qui représentera l'opération commerciale:

public interface IMyService 
{ 
    DomainModel SomeOperation(string input); 
} 

puis d'implémenter ce service. Enfin le contrôleur l'utilisera:

public class MyController: Controller 
{ 
    private readonly IMyService _service; 
    public class MyController(IMyService service) 
    { 
     _service = service; 
    } 

    public ActionResult Create(string input) 
    { 
     var model = _service.SomeOperation(input); 
     var viewModel = Mapper.Map<DomainModel, ViewModel>(model); 
     return View(viewModel); 
    } 
} 

et de configurer votre infrastructure DI pour passer la bonne implémentation du service dans le contrôleur. Remarque: Dans l'exemple fourni, j'ai utilisé AutoMapper pour convertir un modèle de domaine en un modèle de vue transmis à la vue.

Answer 2

Ce que je tends à faire dans mes projets MVC est de garder autant de la logique métier que possible en dehors de mes actions pour que je puisse les tester

Dans certains cas, je crée une couche de service et ensuite utiliser ce

public class QuizRunner : IQuizRunner 
{ 
    private readonly IServiceProxyclient _quizServiceProxy; 
    public QuizRunner(IServiceProxyclient quizServiceProxy) 
    { 
     _quizServiceProxy = quizServiceProxy; 
    } 

    public GameCategory GetPrizeGameCategory(int prizeId) 
    { 
     return _quizServiceProxy.GetGameCategoryForPrizeId(prizeId); 
    } 

} 

public interface IQuizRunner 
{ 
    GameCategory GetPrizeGameCategory(int prizeId); 
} 



private IQuizRunner_serviceClass; 

public AdminPowercontroller(IQuizRunner serviceClass) 
{ 
    _serviceClass = serviceClass; 
} 


public ActionResult Create(string test1) 
    var itemsFromLogic = _serviceClass.Method1(); 
    return View(); 
} 
public ActionResult Index(string test1) 
    var gameCategory = _serviceClass.GetPrizeGameCategory(test1); 
    var viewModel = Mapper.Map<GameCategory, GameCategoryViewModel>(gameCategory); 
    return View(viewModel); 
} 

cela permet mes actions à tester séparément de ma couche de service et sans dépendance

Hope this helps

Paul

Answer 3

La logique métier doit se trouver dans votre modèle de domaine séparé du framework MVC et d'autres éléments.

exemple du monde réel ...

Application (un de mes entités de domaine) Contrôleur:

[HttpPost] 
public ActionResult Withdraw(int applicationId){ 
    //find it from repository or whatever 
    var app=FindApplication(applicationId); 
    //force it do do stuff 
    a.Withdraw(); 
    //send back some response 
    return RedirectToAction("Application",new{applicationId}); 
} 

entité application elle-même:

public class Application{ 
public void Withdraw(){ 
    //check if current user is authorized to withdraw applications 
    Authorize<CanWithdrawApplications>(); 
    //check if application itself can be withdrawn 
    ThrowIf(!CanBeWithdrawn(),"Application can't be withdrawn."); 
    //apply state changes 
    IsWithdrawn=true; 
    //raise domain event 
    Raise(new Withdrawn(this)); 
} 
public bool CanBeWithdrawn(){ 
    return !IsWithdrawn && !Project.Contract.IsSigned; 
} 
} 

Pour en savoir plus sur ce Vous pouvez Découvrez ce qu'est domain driven design.