1. Architectingprofessional ASP.NETMVC applicationsGUNNAR PEIPMANASP.NET/IIS MVP

2. Whos this horror? Name: Gunnar Peipman Job: Chief Everything Officer Company: Peipman Consult Ltd Hobbies: Coding, reading, travelling, beers Shoe number: 44 In family: boyfriend, step father and father Animals: white fluffy bunny Me & MS: ASP.NET/IIS MVP, blogger, speaker Community: ENETA (www.eneta.ee) http://weblogs.asp.net/gunnarpeipman/ 3. Agenda Architect Architecture of web applications Building models Extending user interface Breaking dependencies Surprise topic 4. Architect 5. Tasks of architect Come up with plan how to build application Find solutions to common problems Detect new problems during development Making decisions that have strong impact Helping and consulting developers Having overview of system at all levels 6. Challenges Making complex things work together as one Learning all the time to gain better understanding of softwaredevelopment and the nature of systems Finding and working out new patterns that can be used alsoin future projects Having good understanding of your play-ground 7. One thing ...You don born to be architect you grow to architect,it is long and hard road 8. Architecture ofweb applications 9. Domain logic patterns Transaction Script Table Module Domain Model Most often your own patterns 10. Onion architecture 11. Patterns and project sizePattern Small Medium BigTransaction Script + - -Table Module + + -Domain Model + + +Custom ? ? ? 12. Building models 13. What is model in MVC?Model in MVC can be any class that is used to carry data fromcontroller to view. Its up to you to define the structure and meaning ofmodel. 14. Some suggestions Good model performs no operations when view is rendered Keep models simple Dont put business or data logic to model Dont use business objects as models or part of models 15. Mapping Mapping can be done: manually by writing some code to automate the process using third-party tools I prefer AutoMapper 16. Extending userinterface 17. Why to extend UI? To avoid adding working code to views To keep views smaller at size To avoid repeating same output logic in views Best extensions can be gathered to library for future projects 18. Breakingdependencies 19. Why not dependencies? Tightly coupled coe hard to test and manage Replacing parts of system is not easy Unit testing is hard if not possible Lost flexibility (run system in conceptually different environments) 20. What dependencies to break? Access to data (repositories, data context) Application services layer Access to file storage Access to network resources Logging 21. Now ... 22. ... lets throw STRINGS 23. Thanks, friends!