No more Three Tier - A path to a better code for Cloud and Azure

1. No more Three Tier A path to a better code for Cloud and Azure Marco Parenzan TSAIM13 Edition [Fall 2014]

2. CODE Code can be found in https://github.com/marcoparenzan/TSAIM2013-Core

3. Marco Parenzan Formazione & Divulgazione con 1nn0va Microsoft MVP 2014 for Microsoft Azure Formazione & Progettazione con ITS Kennedy Ricerca e Innovazione con Servizi Cgn www.slideshare.net/marco.parenzan marco [dot] parenzan [at] libero/live [dot] it www.innovazionefvg.net Developer e Architect in .NET e Web Cloud Developer Loves functional programming Some videogames for fun

4. It’s all about responsibility

5. In code RESPONSIBILITY is implemented with encapsulation

6. How ENCAPSULATION is implemented in code?  With Functions  With Classes and Objects  With Interfaces

7. Three tier a model for modular solutions

8. n-Tier  A tier is a responsibility container  Tiers are «stacked»  A tier communicate with two layers, at most! Tier-1 Tier-2 … Tier-n

9. n-Tier  A tier is a responsibility container  Tiers are «stacked»  A tier communicate with two layers, at most!  Ok, not always true  Tier-1 Tier-2 Tier-n …

10. Three Tier  Three is the most famous standard n-Tier configuration  How do tiers communicate each other?  Define responsibility between layers  Have responsibility for «lower» layer  Consume responsibility by «top» layer Data Access Business Logic PresentationData

11. Interfaces == Contract  Contract: agreement between parts  Define:  How are you talking (Interface)  Interface=Sentence  What are you talking about (Model)  Model==Words Contract==Interfaces Model

12. Contracts and Development Teams  «Three» teams can develop independently, if they agree on Contracts Contract DA/BL Contract BL/P

13. Interfaces and Layers  Layers communicate each other via contracts/interfaces Data Access Contract DA/BL Business Logic Contract BL/P Presentation

14. …MEANWHILE, IN THE SQL ROOM…

15. Database (First)  Database is analysis  Database is «contract»  We’ll speak about with #DDD  Up to now, this is a common assumption https://speakerdeck.com/manuelscapolan/the-role-of-the-database-in-a-domain-driven-design-world

16. Scaffolding  http://en.wikipedia.org/wiki/Scaffold_(programming)  …because DB tells you everything   … generate the final code that the application can use to create, read, update and delete database entries…  It creates a model (an abstraction for table) and a Data Access (an abstraction for Database) Model Data Session

17. Database First Three Tier  When we put togeter Three Tier and Scaffolding, we tipically forget (or confuse) Model with Contract  Model is part of the Contract  Data Access is not a contract, but only operations on data Data Access Business Logic  We can only accept, not agree Presentation Model

18. MVC Database First Three Tier Data Access MVC  Modern Web Presentation is Model View Controller  Controller is coordination in Presentation  View is Output Template  Model is…the same DB model…AAARRRGGGHHH!!!!  This is a common mistake  Not the rule of MVC  There is a problem with terms (Model, VIEWmodel, Data Transfer Objects, etc…)  Model because of «modeling» activity, not model from DB! Business Logic Controller View Model

19. Scaffolded MVC Database First Three Tier MVC  Put all togheter + Database First + Scaffolding + Three Tier + MVC + (-Business Logic) = Real bomb! Data Session Controller View Business Logic Model

20. Some common mistakes in scaffolding template

21. Scaffolding Scenario  “Build model from metadata”  You model classes from Database  You model classes for storage (Entity)  Classes as Aggregate of data by ownership  You decide queries during development  Entity is atomic  All or nothing

22. Mistake #1: No encapsulation  No responsibility  Pay attention on code you change.  Your change can have effectes on others…  Manteinance penalty  Cost  Bugs

23. Mistake #2: No scalability  OK it can scale...  …but are you free to choose?  (RDBMS) Database First is a costraint  Vertical scalability as the only opportunity  Horizontal scalability is no more an opportunity  Performance penalties  Speed  Money

24. Mistake #3: Modeling, not Model!  Model in MVC is the result of a modeling activity, not a model from OR/M!  There are many models types  View Models  Domain Models  Anemic Models  …  DB is not a contract

25. Mistake #4: one model does not fits for all  Foremost, Model is «stretched» as contract between all tiers  Because it’s DATABASE model, not BUSINESS model  One model for DYNAMIC queries  Because you don’t know which queries you need  No queries in analisys

26. A road to a (more) modern model Presentation has its own model No more ONE model

27. Presentation models  “Create/Read/Update/Delete model”  You model classes from Scenarios  You model classes for view (ViewModel)  You can decide queries during development  Mapping is a valuable costing  ViewModel is atomic  ViewModel map to some part of an entity

28. ViewModel  Is a model of an entity optimized for UI  No Database-like references  An entity object is not suitable for universal usage  No localization  Data already decoded  Data already loaded (if good to)  A ViewModel is typically an “pure” “language” object  Minimize (down to zero) needs of getting other data from other sources

29. Queries in analysis  Define ViewModels in analysis  All data required are in analysis  You identify queries needed to map data from/to database  You start identifying tests

30. Pro & Cons….Cons?  In a ViewModel you have “parts” of a Database model  You can have MANY viewModels that corresponds to a single Database Model  Is this a cons? No  Cons  Many, not one  Slow…more to code  Pro  More testable  Fast…code at runtime

31. A road to a (more) modern model A lap around CQRS

32. Decide what you need to do  Don’t make implicit choices  Don’t choose for others  Pretend to know what they need to do

33. Decide what you want to do then  It’s your intention  You decide an action to do  That’s action is composing a command

34. Send you command  Command object is a object that assert an intention to an action  All values assigned to properties specify parameters of the intention of the command  Typically, this kind of objects are flat (not complex)  Typically this object have no particular dependencies  Don’t expect immediate execution  Ccommand can be queued

35. Data Transfer Object - DTO  An object that carries data between processes in order to reduce the number of method calls (http://martinfowler.com/eaaCatalog/dataTransferObject.html)  An aggregate of information  A mono-directional object optimized for data presentation  Typically is a result of mapping of a generic query from a datasource

36. Recap CQRS Scenario  “Command/Query Responsibility Segregation”  You model classes from requests and responses  You model classes for actions (Commands) and queries  Classes as aggregates of parameters (Commands) and aggregates of values (Data Transfer Objects)  You need to decide queries during development, because Model can be huge  Command is atomic, DTO is atomic  ViewModel work to

37. CQRS defined  CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young  At its heart is a simple notion that you can use a different model to update information than the model you use to read information  This simple notion leads to some profound consequences for the design of information systems.  From Martin Fowler  http://martinfowler.com/bliki/CQRS.html

38. Comparing Application Scenarios Scaffolding View Models CQRS Development Time (perceived, initially) Low Average High Development Cost (to long) High Average Average Complexity High Average Low Testability Low Average High Overall Quality Low Average High

39. Model costs 600 500 400 300 200 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Scaffolding ViewModels CRUD CQRS cost is substantially costant through the implementation of the entire loop

40. Evaluating Application Scenarios  Founding Principles  Application Lifecycle Management  Scrum  Maintainable Code  Parameters  Development Cost (perceived, initially)  Development Cost (to long)  Complexity  Testability  Overall Quality

41. Scalability Scenarios

42. Scalability  From Wikipedia  Scalability is the ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth  In another way  Scalability describes the ability to keep constant the handling time of a request as amount of work growth.

43. Ways to manage scalability  Scaling Up  Get it bigger  Be carefull about single points of failure  Scaling Out  Get it more that one  Be careful about state  Async  Give it the right time  Decoupling in time  Queuing  Decoupling in tiers

44. Managing demand Don’t forget you are also paying for unnecessary software licencing while you are over capacity TIME IT CAPACITY Actual Load Allocated IT-capacities Too Much Power Load Forecast Potential business loss Wasted capacity Not Enough Power

45. Predictable Bursting Services with no seasonality trends No particular peaks IT complexity, no wasted capacity Uso «sostanzialmente» costante Applicazioni interne

46. Unpredictable Bursting Marketing On-Time Offer Aperiodical Dues Special Event Unexpected/unplanned peak in demand Sudden spike impacts performance Can’t over provision for extreme cases Average Usage

47. Periodical Bursting Marketing Periodical Offer Periodical Dues Special Repeatable Events Services with micro seasonality trends Peaks due to periodic increased demand IT complexity and wasted capacity

48. On/Off Bursting Digital media rendering and encoding Financial and insurance risk calculation Engineering modeling and simulation Computational life sciences Earth sciences Data analytics On & off workloads (e.g. batch job) Over provisioned capacity is wasted Time to market can be cumbersome

49. Growing Fast Social Media Web Games Successful services needs to grow/scale Keeping up w/ growth is big IT challenge Cannot provision hardware fast enough Average Usage

50. Scaling  Scale up by choosing different VM sizes  Scale out by adding more instances  Scale-out automatically with Elastic scaling  Scale out static content with CDN to distribute user traffic  Scale out low-variable data with caching to offset server workloads

51. Async to scale? It depends…

52. (A)Syncronous  Syncronous (relation) between a client and a server is when server MUST respond to client request and client have to wait ACTIVELY for server response.  Asyncronous, in a web context has two situations  Client SideAsyncronous is for responsiveness  Server SideAsyncronous is for scalability  Responsiveness  Don’t block UI thread so user can continue interacting with app while request is currently running  Scalability  Increase the usage of the thread pool while a request is blocked for I/O

53. “Async” scale-up  Sync cause “scaling up”  You can only increase resources because “sync” scenario tends to “lock” resources  Async lower the need of scaling up  Resources are better used  Async is not useful to scale out

54. A queue to scale

55. Let command be executed to whom is really responsible  Async client  Responsive  Async server (MVC action)  Scalable  ‘Still synchronous when executed by MVC role  MVC is “front end” role to the client  Syncronous implies “give a response”  Really?  It’s really needed

56. Response vs. “acknowledge”  Syncronization is needed to obtain an answer  What’s in the answer?  Result  Acknowledge  Result  What you expected from execution of the request  Acknowledge  Response about “taking responsibility” on request, but not the result  Why not the result  Typically because it take too long to obtain response  Async (client/server) is always “pretend an answer” inside a timeout ….in seconds on average  Many scenarios cannot have this  Order management  Interop with legacy systems  …

57. Command as a serializable request  Command is the metaphor for the request  Useful to be serializable  Serializable is useful to store/persist/”suspend”  Why “suspend”?  Because a long time to execute  Executor is overloaded  Executor is doing something else  Executor need it’s time to execute  Where serializing?  Somewhere where “taking out” is a principle  For example “FIFO” structures: queues

58. Using Queues  Queue are useful to receive commands  MVP frontend role just acquire commands  Commands are syntactically validated  Commands are just queued  (a)sync response from frontend is quick  Just acknowledge the insertion of command into queue MVC Frontend Role Controller Command Action Command Command Queue Command Command Command Command Command Command

59. A worker to scale

60. Commands in a queue  When Commands are in queue, who take commands out?  Command Handler is the generic concept  A CH handle a command  Many commandsmany command handlers

61. Domain in the CH  Command Handlers execute command  Act on the domain  Call aggregate entity methods  Mapping command parameters  Typically Commands are not domain objects

62. Workers  A command handler must be hosted in a process  Process are typically NON-UI processes  simple, Light  end-less (infinite loop)  Sleepy (suspend themselves each loop)  Stateless (no global variables, just loop function)  Horizontally scalable (execute many in parallel, in the same machine, in many machines)  Typically Console.exe apps (in .NET)  Estract message from queue and execute it  Support  Retry logic  Priority logic

63. An event to scale

64. Don’t take more responsibility: inform about what you have done  A worker is the identity that implements CH and act on then domain  A worker knows the domain through aggregates  Aggregate know only its domain  What about impacts about acting on the domain?  Copies of data somewhere else  Perform other actions into other domain  Have the aggregate knowledge about effected?  No  Aggregate must declare that Something has happened  An event  An event is the knowledge of something happened in the history  An event must be shared with anyone  …interested about event

65. Event queue  Events generated by aggregate must be collected in a structure that shares event to many  Publisher/subscriber pattern  Many listener “subscriibe” to the event queue  A subscriber declare which messages are interesting Aggregate Method 1 Event Event Queue Event Event Event Event Event Event Listener Listener Listener Listener

66. Push data on the web

67. Responses: where are they  Client have done a request/a command  Client have received an acknowledge  Domain has executed the command  A result have happened…yes….?!?!?!?  A result is the execution of the command  A result is found  When? When event is notified  Where? Event give all and enough information to RETRIEVE the result, not the result itself  Client knows following the event which is the result to be retrieved

68. Pull/Push communication with client  How client knows about events?  Pull way  Client request from an event queue if it have and event  Events must be stored  Client have to query events queue to check if there are some new events  Push way  Server will reach client and send it an event message  Modern way with Web Sockets (in a Web scenario)  SignalR in ASP.NET

69. Retrieve the result  Event contains information to retrieve the result, not the result itself  Some keys, ids  Some display data  Event is a DTO  Event is enough to get other DTOs, for example  Event can be used to trigger other actions

70. No more Three Tier A path to a better code for Cloud and Azure Marco Parenzan TSAIM13 Edition [Fall 2014]

No more Three Tier - A path to a better code for Cloud and Azure

No more Three Tier - A path to a better code for Cloud and Azure

Recommandé

Contenu connexe

En vedette

En vedette(6)

Similaire à No more Three Tier - A path to a better code for Cloud and Azure

Similaire à No more Three Tier - A path to a better code for Cloud and Azure(20)

Plus de Marco Parenzan

Plus de Marco Parenzan(20)

Dernier

Dernier(20)

No more Three Tier - A path to a better code for Cloud and Azure

Notes de l'éditeur