220 likes | 344 Views
WEB402: Design Considerations for ASP.NET MVC Applications. Dino Esposito R&D Manager Crionet Solutions (dino.esposito@crionet.it). Content. Controllers Structure of the class & implementation of methods Injection of dependencies Defining data models for the views Action filters and AOP.
E N D
WEB402: Design Considerations for ASP.NET MVC Applications Dino Esposito R&D Manager Crionet Solutions (dino.esposito@crionet.it)
Content • Controllers • Structure of the class & implementation of methods • Injection of dependencies • Defining data models for the views • Action filters and AOP
Controller methods vs. Button1_Click • Abstractly speaking, some inherent similarities exist … public ActionResult Index(...) { // Perform the expected task // and render the next view } public void Button1_Click(...) { // Perform the expected task // and update server controls }
Role of the controller Button1_Click Controllers Tightly bound to user requests Further layering is up to you Full testability … if dependencies are properly managed Input data comes from parameters Response results from view engines • Tightly bound to events • Further layering is up to you • Impractical to test • … even when layered • Input data comes through server controls • Response results from server controls
What flavor of controller would you like?Applicable stereotypes from RDD • Service Provider • Performs work • Controller • Makes decisions and closely directs the actions of other objects • Coordinator • Reacts to events by delegating tasks to others
Fat-free controllersLean and mean collections of endpoints • Extremely simple action methods • Single call to get data for the view • Yield to the view engine • Grab exceptions via attributes • Who really does the job? • Controller delegates to other components the task • Arranges data into a view model
Fat-free controllers Dream code Handles all exceptions as may be raised • [HandleError] • public class BookingController : Controller • { • public IBookingControllerActionServiceActionService { get; private set; } • public BookingController(IBookingControllerWorkerService service) • { • Contract.Requires<ArgumentNullException>(service != null); • ActionService = service; • } • [BookingAddHandleError] • public ActionResult Add(BookingAddInputModelinputModel) • { • Contract.Requires<ArgumentNullException>(inputModel != null); • var model = ActionService.InsertNewBooking(inputModel); • return View(model); • } • : • } Handles any exceptions raised within the action Unpacks input data Calls the middle tier Creates view model Packs data into model
Action servicesPart of the presentation layer Controller Exception layer Action Action Action Input View model Action exception service Action exception service Action exception service Action Service Action Service Action Service Service (Application) Layer Domain Model Data Access Layer
Fat-free controllers demo
One step furtherDo we really need controllers? • Is the controller a mere pass-through layer? • Stateless and mere container of (rich & componentized) actions • Fundamental part of the ASP.NET MVC deal • Food for thought • Controller-less actions • Command pattern in a custom invoker • Instantiate an action object with methods based on HTTP verbs • Implementation: still needs to implement IController
View ModelsData worked on in the view • Classic weakly-typed approach • ViewData works well, easy to use, easy to understand • Strongly-typed approach • Avoid magic strings/casts, catch errors at compile time, IntelliSense • IMHO, only viable option in medium-sized applications • Dynamic approach • Based on dynamic type in .NET 4
Dynamic view models demo
Frequently required componentsController factory • Every requests passes through the controller factory • Write yours and gain control over the request lifecycle • Nice things to do • Set your tailor-made invoker • User ad hoc controllers for some types (or bypass controllers) • Plug in your favorite IoC framework • Trigger MEF composition
Frequently required componentsAction invoker • Controls the performance of any action for a controller • Write yours and gain control over the code being executed • Nice things to do • Set culture on the current thread • Add/remove action filters • Override methods to control/alter request lifecycle
Action filtersNative aspect-orientation of ASP.NET MVC • Pre/post process actions • Pre/post process generation of action results • Built-in filters • Authorization, error handling, output caching
Action filtersGallery • Detect which of many submit buttons was clicked • Complete the view model with common/shared data • Compress/Track/Customize output • Build browser-specific views for any action • Load filters dynamically (from a configuration file)
Conclusions • Fat-free controllers • Strongly-typed view • Single Responsibility Principle • Leverage built-in capabilities (binding, filters, contracts) • Build your own facilities on top of ASP.NET MVC capabilities
Session Evaluations Tell us what you think, and you could win! All evaluations submitted are automatically entered into a daily prize draw* Sign-in to the Schedule Builder at http://europe.msteched.com/topic/list/ * Details of prize draw rules can be obtained from the Information Desk.
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.