2009-05-12 5 views
3

Je connais l'idée de base du principe du tonnerre (un objet entre, un objet sort) mais je n'en ai vu aucun exemple réel dans asp.net mvc. Est-il bon exemple de thunderdome principethunderdome action invoker asp.net mvc

public ActionResult Index(Employee employee) 
     { 
      //some actions here 
      return View(employeeViewModel); 
     } 

Mais qu'en est-déclaration

Les classes de contrôleur ne sera jamais directement exposé à tout ce qui touche à HttpContext

Comment l'invocateur d'action devrait ressembler? Pourriez-vous fournir quelques exemples et tests unitaires pour cela?


de http://codebetter.com/blogs/jeremy.miller/archive/2008/10/23/our-opinions-on-the-asp-net-mvc-introducing-the-thunderdome-principle.aspx

Le « Thunderdome Principe » - Toutes les méthodes de contrôleur prennent dans un objet ViewModel (ou zéro objets dans certains cas) et le retour d'un seul objet ViewModel (un objet entre, un objet feuilles) . Les classes Controller ne seront JAMAIS directement exposées à quoi que ce soit lié à HttpContext. Rien ne me fait pleurer comme voir des gens essayer d'écrire des tests qui se moquent de cette nouvelle interface IHttpContextWrapper. De même, les méthodes Controller ne renvoient pas d'objets ViewResult et sont généralement découplées de toute l'infrastructure MVC. Nous avons adopté cette stratégie très tôt afin de simplifier mécaniquement les tests du contrôleur.

Mais je veux savoir comment faire? comment écrire un tel invocateur d'action de contrôleur? Parce que nous devons normalement nous moquer de httpcontext

Répondre

1

Il existe un exemple d'implémentation d'un invocateur d'action OMIOMO (Thunderdome) dans ASP.NET MVC dans la source Oxite rev2.

Plus précisément, le OxiteActionInvoker: http://oxite.codeplex.com/SourceControl/changeset/view/31497#442766

Et vous pouvez voir un contrôleur qui est OMIOMO: http://oxite.codeplex.com/SourceControl/changeset/view/31497#442745

également d'intérêt, les gars Oxite ont pu le faire pour que vous puissiez vous avoir COI- filtres d'action capables (vs avoir à spécifier tous vos filtres sur les actions - une violation OCP possible puisque l'action devrait alors connaître toutes les manières possibles dans lesquelles il serait utilisé). Vous pouvez le voir en action dans la méthode OxiteActionInvoker "GetFilters" où il frappe le FilterRegistry pour charger tous les filtres enregistrés pour cette action.

0

C'est l'approche la plus propre "principe de tonnerre (un objet entre, un objet sort)" pour les applications MVC. Vous devriez toujours essayer de faire des trings avec ce style, et évitez d'utiliser ViewData ou ViewTemp pour obtenir vos données nécessaires dans la vue.

Pour un exemple simple, vous pouvez regarder dans le projet jscportal ici link text

par exemple dans le jscportal\JSC.Portal.Web\Controllers\TemplatesController.cs vous aurez leurs exemples comme vous voulez:

public ActionResult List() 
{ 
    IList<Template> templates = Service.GetAll(); 
    return View(templates); 
} 

public ActionResult Edit(int id) 
{ 
    Template t = Service.GetById(id, false); 
    return View(t); 
} 

bonne chance!

+0

Oui, mais qu'en est-il de cacher httpcontext ?? et à propos de tester un tel contrôleur? –

+0

Si vous le laissez comme ceci, que vous devrez reprendre vos tests à ce qui se passe dans le service, supposons que vous testerez dans ce cas seulement les possibilités qui proviennent des dépôts. Si vous voulez aller dans HttpContext que vous pouvez utiliser des idées de piraté: voir http://haacked.com/archive/2007/12/09/writing-unit-tests-for-controller-actions.aspx – diadiora

Questions connexes