Modeling best practices

November 2010 Modeling Tips, Tricks and Best Practices A Tutorial on the M in the MVC

Who Am I? •Ralph Schindler (ralphschindler) Software Engineer on the Zend Framework team • Zend for almost 3 years • Before that TippingPoint/3Com Programming PHP for 12+ years Live in New Orleans, LA. • Lived in Austin, Tx for 5 years 2

Where Can You Find Me? •Online Website/Blog: http://ralphschindler.com Email: ralph.schindler@zend.com Twitter: @ralphschindler Slides: http://www.slideshare.net/ralphschindler IRC: freenode:ralphschindler / efnet:rschind • #zftalk.dev #zftalk #doctrine #li3-core #nolainteractive 3

Tutorial Outline •What modeling is •Evolution of models in PHP •How models fit into an application •The roles and responsibilities of a model •Emerging modeling practices •Useful patterns for modeling in PHP •Looking at a full from scratch application Look at variations with a model framework like Doctrine 4

What Is Modeling?

The Model In General •Address the complexities of a “Problem Domain”: All of the expertise, processes or resources need to solve a particular problem Excluding everything else Problem Domain is finite, and solvable http://en.wikipedia.org/wiki/Problem_domain 6

The Model In General •Not strictly a object-oriented concept, but ... Can exist in procedural / functional / imperative languages Predominant in OO: • “Object-Oriented Modeling” / OOM http://en.wikipedia.org/wiki/Object-Oriented_Modeling 7

The Model In General •Highly conceptual approach to software design Less deviation between code and the thing it models •Everything becomes a noun Easy to encapsulate things as a model, or noun While you have real world processes that you “do” or “carry out”, they must be codified as “things” in your application Adjectives become nouns too 8

Object Oriented Modeling •Object oriented languages are well suited modelers: Classes = Domain Objects = An instance of the Domain / Domain Member Methods = Domain member behavior Static Members = Domain state & behavior 9

Object Oriented Modeling •Continued in-depth: Namespaces = Hierarchical organization of domains References = Relationships of domain members Inheritance = Variations in domain complexity Visibility = Rules of how domain members interact 10

Modern Modeling In Computing History •Smalltalk released in 1980 Revolutionary: object oriented, dynamic type, reflective “Everything is an actor” Actors behave based on the message they receive and emit •Led to an increased popularity of “Model Driven Engineering” A favoring of domain concepts over algorithmic concepts http://en.wikipedia.org/wiki/Smalltalk http://en.wikipedia.org/wiki/Actor_model http://en.wikipedia.org/wiki/Model-driven_engineering 11

Modern Modeling In Computing History •Smalltalk led to development of: Computer-Aided Software Engineering (CASE) • ER Diagrams • Data flow diagrams • Structure charts • Decision trees • Decision tables http://en.wikipedia.org/wiki/Computer_Aided_Software_Engineering 12

Modern Modeling In Computing History •Smalltalk then influenced Java Released in 90’s, funded by Sun Object-oriented • “everything is an object” • Class based objects, single inheritance, multiple interfaces derived from C & C++ in syntax • Automatic GC, memory management, further away from the computer (abstraction) http://en.wikipedia.org/wiki/Java_(programming_language) 13

Modern Modeling In Computing History •As it relates to us: PHP born in 1995 • Highly procedural & functional language • Mostly scalar types PHP 5 in 2005 • Better object-oriented system • Object model similar to Java’s http://en.wikipedia.org/wiki/PHP 14

Evolution of PHP Models

In The Beginning ... •Procedural applications A series of scripts that together fulfilled a purpose, together known as an “application” •Model1 Architecture Coined in the Java community •PHP + MySQL Early PHP “applications” were Model1 architected http://en.wikipedia.org/wiki/Model_1 16

Model1 Architecture 17

Model1 In PHP 18

Separation Of Concerns •Definition: The process of separating a computer program into distinct features that overlap in functionality as little as possible •Keywords: Transparency, encapsulation, modularity, layered http://en.wikipedia.org/wiki/Separation_of_concerns http://en.wikipedia.org/wiki/Model_2 19

The First Separation Of Concerns •Smarty Allowed for deviation of presentation from business logic •Templates •Early Frameworks & Persistent Layer Abstractions creole, propel http://www.smarty.net/ http://www.propelorm.org/wiki/Introduction 20

The First Separation Of Concerns 21

New Kid On The Block •Ruby On Rails Released 2005-ish •ActiveRecord •MVC - A Model 2 Architecture Promotes further separation of concerns in various aspects of a application http://en.wikipedia.org/wiki/Ruby_on_Rails http://en.wikipedia.org/wiki/Model2 22

PHP 5 •5.0 Released in 2004 •5.1 in 2005, 5.2 in 2006 •Features: Zend Engine II with a new object model, similar to Java and C# • Abstracts, visibility, interfaces, iterators, inheritance http://us2.php.net/oop5 23

PHP Playing Catchup •Early MVC Frameworks Started appearing around 2005 after RoR craze started •ActiveRecord (a la RoR) could not work in PHP Late static binding was an issue, other solutions found • Model / base class generation • Mappers and other patterns http://en.wikipedia.org/wiki/Active_Record_Pattern#Ruby 24

MVC Frameworks •2005-2006 Symfony CakePHP Qcodo CodeIgniter http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP_2 25

“Model != Database” •PHP community has always had a strong relationship with the MySQL database platform •“99% of the applications written before 2005 were php+mysql” •2007-2008: after MVC has become as well known pattern messaging started that model != database 26

Model != Database (or does it?) 27

Learning From Java & .NET Community •Patterns of Enterprise Application Architecture Patterns you are somewhat familiar with: • MVC, Active record, Factory • Mapper, Registry, etc Bible of application patterns http://www.amazon.com/gp/product/0321127420 28

Learning From Java & .NET Community •Domain-Driven Design Taking M (Domain Model) in MVC to a new level • Repositories, Entities, Value Objects • Factories, Aggregate Roots Book has 2 distinct perspectives • execution • team & human infrastructure http://www.amazon.com/gp/product/0321125215 29

If DDD Is Too Dense •Domain Driven Design - Quickly The “cliff notes” version of DDD by Eric Evans On Google: • http://www.google.com/search?q=domain+driven+design+quickly+download http://www.infoq.com/minibooks/domain-driven-design-quickly 30

Coding & PHP Best Practices ... Applied to Models

PHP The Platform •Never forget the nature of PHP: “Application” exists in the scope of a request Shared-nothing architecture / horizontally scalable • Static & global scope destroyed at end of each request Is not “pure” object oriented • Scalar types that are not objects: strings, integers, stdClass.. •Use the platform to your advantage 32

PHP Application Architecture 33

Java / .NET Architecture 34

Application Scope 35

Coding Standards (The Important Parts) •Stick with a coding standard that makes sense: Zend Framework, PEAR standard • Single class per file • Hierarchical naming prefix – This is in lieu of true namespaces •Use an autoloader This helps put emphasis on organization as well as being a performance enhancement http://framework.zend.com/manual/en/coding-standard.overview.html http://framework.zend.com/manual/en/zend.loader.autoloader.html 36

Use PHP’s Built-in Features •Get to know all of the OO features of the language Constructors, Visibility, object iteration, ... Overloading: • __get(), __set(), __isset(), __unset() Magic methods: • __construct, __clone, __toString, __call, __sleep, __wakeup Type hinting, Serialization, References, etc http://www.php.net/manual/en/language.oop5.php 37

SPL: The Most Useful of OO Facilities •Data structures Heaps, Stacks Queues, ObjectStorage •Iterators DirectoryIterator, SimpleXmlIterator, ArrayIterator, FilterIterator RecursiveIterator, RecursiveCachingIterator, RecursiveIteratorIterator, http://php.net/spl 38

SPL: The Most Useful of OO Facilities •Exceptions of all types InvalidArgumentException, RuntimeException, DomainException, BadMethodCallException, DomainException, UnexpectedValueException •Functions spl_autoload_register, spl_object_hash, ... 39

Generally Accepted Best Practices •Using mutator & accessor methods keeping properties protected setProperty() & getProperty() •Minding visibility High expectation that developer will consume and extend your codebase, avoid final and private visibility 40

Mind Your Globals / Static State •One of PHP’s strengths is also its weakness Shared-nothing architecture encapsulates the application scope within a request •Practice good Dependency Injection This will allow you to create more maintainable, more testable and easier to understand code 41

Singleton-itis 42

Testing Singletons 43

Models in Applications

Multitiered Architectures •Linear architecture Presentation Application/Logic Data •Physical layers http://en.wikipedia.org/wiki/Multitier_architecture 45

Multilayered Architecture •Pattern driven / object oriented •Generally applies to the software architecture •Layers: UI Application Domain Infrastructure http://en.wikipedia.org/wiki/Common_layers_in_an_information_system_logical_architecture http://en.wikipedia.org/wiki/Multilayered_architecture http://en.wikipedia.org/wiki/Layer_(object-oriented_design) 46

Multilayered Architecture Examples •MVC: Model-View-Controller •PAC Presentation-Abstraction-Control HMVC: Hierarchical Model-View-Controller • ZF “kinda” has this with controller “modules” •MVP Model-View-Presenter •MVVM Model-View-ViewModel http://en.wikipedia.org/wiki/Model_View_ViewModel http://en.wikipedia.org/wiki/Model_View_Presenter http://en.wikipedia.org/wiki/Model_View_ViewModel http://en.wikipedia.org/wiki/Presentation-abstraction-control 47

What MVC Is •Model-View-Controller, an application architecture •Coined in 1979 by Trygve Reenkaug at XPARC (same place Smalltalk was being created) consequently started work on UML http://en.wikipedia.org/wiki/Model–View–Controller http://en.wikipedia.org/wiki/Trygve_Reenskaug 48

Roles within MVC •Model Domain logic, business logic, problem area, generally the reason you started writing the application in the first place •View UI Layer, Presentation Layer •Controller Interpretation of interaction with view within context 49

Web MVC (In A Picture) Oversimplified and generally hard to apply to the web 50

Web MVC (In A Better Picture) 51

MVC in PHP •Model Object oriented approach to codifying a business process or concept Persistence layer: Database, web services, i/o (In the strictest sense) NO UI/Transformation Tech: • HTML, CSS, Flash, XML (in most cases), JSON, Yaml, etc No environmental specifics: • No $_GET, no $_POST, no $_SERVER, no $_SESSION 52

MVC in PHP •View UI Specifics • HTML, Javascript & JS generation, CSS & CSS generation Iteration and display of Models Limited interaction with Models: • Views should not mutate a model’s state, only present it Limited interaction with Controllers • Views should avoid dispatching controllers in the same request 53

MVC in PHP •Controllers Heavily environmental specific: $_POST, $_GET, $_SESSION Coordinate application request with Model interaction • Most model mutation should happen within a Controller No UI concerns (this belongs in the view) Other behaviors: • Http redirects, coordinating layouts and response types No direct data persistence 54

Our Fictitious Domain Everyone Knows What A Snowball Is Right?

What Is A Snowball? I am your Domain Expert 56

Is It Popular? 57

So Why An Application? •Track where all snowball stands are hours, location, other products •Create a history of the ones we’ve visited “What we’ve tried, what we liked” •Create a list of “the best” favors, most liked flavors, and most unique flavors •Expand to FB user base Create a game out of trying the most at the most 58

Patterns In PHP - Useful To Models Putting the Tools in your Toolbox

Model: Concept vs. Implementation •As a concept: Is not a physical codified “thing” Represents a set of things that make up the business portion of an application Things = entities, relationships, processes •In implementation: In OO/M: can be a class, or a set of classes Generally comprised of several patterns, not just one 60

Basic Pattern: Mapper •Name: Mapper •Description: An object that sets up a communication between two independent objects. Two systems exist that are ignorant of one another • (by design or by choice to limit dependencies) http://martinfowler.com/eaaCatalog/mapper.html 61

Basic Pattern: Mapper •When to use it: Domain concepts do not match non-domain concepts • An object in-memory is represented as an object graph (multiple reference objects), but in persistence it is represented as a flat database row Names in the domain are different than names outside the domain (first_name vs. FirstName) 62

Basic Pattern: Mapper 63

Basic Pattern: Registry •Name: Registry •Description: A well-known object that other objects can use to find common objects and services. Generally accessed by name, or at a specific known location http://martinfowler.com/eaaCatalog/registry.html 64

Basic Pattern: Registry •When to use it: You need a container of non-like objects Objects that may (or may not) be required within a framework Registry is an object that can be utilized in DI • Pass the registry instead of all of the potentially required objects • Your domain/framework/applications scope is not infinite Generally setup all at once, not intermittently 65

Basic Pattern: Registry •Commentary: Java community builds long running multi-threaded applications PHP applications tend to be: • modularized, minimal dependencies that need to be injected, consistent & common dependencies A registry need not be static, nor global in any way 66

Basic Pattern: Registry 67

Basic Pattern: Gateway •Name: Gateway •Description: An object that encapsulates access to an external system or resource Allows for a normalization of a 3rd party API: database system, web service, xml structure- things that don’t look like objects in the system you are developing http://martinfowler.com/eaaCatalog/gateway.html 68

Basic Pattern: Gateway •When to use it: On an externalized (or seemingly externalized) portion of a system you have an awkward API to interact with • “protected variation” 69

Basic Pattern: Gateway 70

Basic Pattern: Factory •Name: Factory •Description: The factory pattern is a creational design pattern used in software development to encapsulate the processes involved in the creation of objects http://en.wikipedia.org/wiki/Factory_pattern 71

Basic Pattern: Factory •When to use it: Object vs. Method- where does the API feel most right? Composition and setting up a valid state for an object is too complex for a __construct() Object type might vary (dynamic factory) • inheritance, design-by-contract, interfaces, etc.. 72

Basic Pattern: Factory 73

Patterns In PHP: O/R Patterns •O/R = Object Relational Patterns •Deal with 3 areas of concern (in PoEAA) Mapping of metadata • Everything you can know about a DB, but described in OO Structural patterns • How physical objects relate to physical database concepts Behavioral patterns • How database behaviors can be related in OO facilities 74

O/R Pattern: Metadata Mapping •Name: Metadata Mapping •Description: Holds details of object-relational mapping in metadata In Database usage: • information about columns, their types, ordinal position, table contained within, schema contained within, etc http://martinfowler.com/eaaCatalog/metadataMapping.html 75

O/R Pattern: Metadata Mapping •When to use it: Knowing information about a column is important: • primary key / key info, types, nullable, .. other structural info Knowing how to map OO concept to the DB concept Very common b/c names are simply not the same on both ends of the spectrum: FirstName => first_name 76

O/R Pattern: Metadata Mapping 77

O/R Pattern: Query Object •Name: Query Object •Description: An object that represents a query Provides a layer of abstraction between the model and the persistence layer with respect to how criteria is used when finding data http://martinfowler.com/eaaCatalog/queryObject.html 78

O/R Pattern: Query Object •When to use it: Complex SQL fragments are creeping into your domain layer Really need to understand the full scope of your querying needs • Commercially supported query framework • Take on building a small framework that will fill your needs 79

O/R Pattern: Query Object 80

O/R Pattern: Repository •Name: Repository •Description: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain object (more on this later) http://martinfowler.com/eaaCatalog/repository.html 81

O/R Pattern: Repository •When to use it: Need to find existing domain objects / entities, ultimately from your data source Used in conjunction with a query object Specification based approach vs. the finder() method approach of a data mapper Complete abstraction away from database “sets” Wide variance of query types Variance of “query strategy” placed in this layer 82

O/R Pattern: Repository 83

Data Source Pattern: Table Gateway •Name: Table Gateway •Description: An object that acts as a Gateway to a database table, one instance handles all the rows in the table http://martinfowler.com/eaaCatalog/tableDataGateway.html 84

Data Source Pattern: Table Gateway •When to use it: Simplest form of OO to DB gateway Expose DB centric behaviors: • insert(), update(), select(), delete() In PHP, less expensive, and can leverage base types / scalar types in return sets • Faster when pushing through more information (data warehousing) 85

Data Source Pattern: Table Gateway 86

Data Source Pattern: Row Data Gateway •Name: Row Data Gateway •Description: An object that acts as a Gateway to a single record in a data source, there is one instance per row Row specific operations: • save(), delete() http://martinfowler.com/eaaCatalog/rowDataGateway.html 87

Data Source Pattern: Row Data Gateway •When to use it: Like Active Record, very good in small & medium projects • Where domain model has a very close relationship to the DB Downside, large projects that use a mapper anyway would lead to duplication of objects in various layers Adding business logic to your row data object transforms it into an Active Record object 88

Data Source Pattern: Row Data Gateway 89

Data Source Pattern: Active Record •Name: Active Record •Description: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data 90

Data Source Pattern: Active Record •When to use it: Small & medium projects that would not benefit from more layers of abstraction • Can be used as the persistence layer of a Domain Model • Fewer complex relationships between domain member concepts and objects • Database has a strong resemblance to the Domain Model A good pattern to utilize when refactoring an older Model 1 application 91

Data Source Pattern: Active Record 92

Data Source Pattern: Active Record •Commentary: This is probably the most popular of “modeling” data access gateways This is actually NOT a bad pattern! Active Record generally reflects the project itself • PHP based - (Good, Fast, Cheap - Pick Two) Provides the most “bang for the buck” http://en.wikipedia.org/wiki/Project_triangle 93

Data Source Pattern: Data Mapper •Name: Data Mapper •Description: A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself 94

Data Source Pattern: Data Mapper •When to use it: With a Domain Model, particularly when domain concepts do not have a 1-1 relationship to database implementation 95

Data Source Pattern: Data Mapper 96

Domain Logic Pattern: Domain Model •Name: Domain Model •Description: An object model of the domain that incorporates both behavior and data 97

Domain Logic Pattern: Domain Model •When to use it: There is a lot of complexity in a target system’s design • Processes, concepts, integration points You can afford to properly do it  98

Domain Logic Pattern: Domain Model 99

Domain Logic Pattern: Table Module •Name: Table Module •Description: A single instance that handles the business logic for all rows in a database table or view 100

Domain Logic Pattern: Table Module •When to use it: Your target system is “table oriented” • Sets of data, instead of individual rows – “Record Sets” • Data-warehousing 101

Domain Logic Pattern: Table Module 102

Domain Logic Pattern: Service Layer •Name: Service Layer •Description: Stateless set of operations Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation Own its own, it is a loaded concept • There are various layers that might container a service layer 103

Domain Logic Pattern: Service Layer •When to use it: (Domain Service Layer) Business logic that does not fit clearly in a domain models scope (Application Service Layer) Further separation between the API that the controller speaks to • This also provides a more cohesive API that the application understands, fewer “domain parts” to interact with 104

Domain Logic Pattern: Service Layer 105

Domain Logic Pattern: Service Layer •Commentary: The true meaning behind services in each “layer” Variety: • Application Services • Domain Service 106

Data Patterns: Entity Object •Name: Entity Object •Description: An object in a Domain Model that has an identity 107

Data Patterns: Entity Object •When to use it: These are generally the models or members of the domain that is being modeled They encapsulate both data and behavior With their identity, can be found by a canonical name within a data source 108

Data Patterns: Entity Object 109

Data Patterns: Value Object •Name: Value Object •Description: An object who does not have an identity 110

Data Patterns: Value Object •When to use it: When there is data where identity is not important • Situations where data can benefit from becoming an object – Additional behavior, conform to an existing interface – Polymorphic behavior 111

Data Patterns: Value Object 112

Problems & Solutions Hands On Time

The Conceptual Architecture •Multilayered UI / Presentation Layer Application Layer Domain Layer Infrastructure Layer •Implementation Pattern: MVC 114

Layers Of A Domain Driven Architecture 115

Domain As Part Of An Application •First decide if your Models should be a separate project from your application Separate projects offer a clear distinction between application layer concerns and domain layer concerns Models as part of an application project allow a streamlined development process, one less thing to manage 116

Domain As Part Of An Application Here? Or Here? 117

Choose The High Level Implementation •Choose an application framework In our case, Zend Framework 1.x • MVC architecture, PHP 5.2 & PHP 5.3 (non namespaced) •Start by matching up the concepts: How does the application framework perceive a separation of concerns? How is it implemented? 118

Lining Up The Concepts To Our Application Framework •UI / Presentation Layer Views, View Helpers, Layouts •Application Layer Application & Bootstrapping, Controllers, Action Helpers •Domain Layer Model/Entity, DbTable, Service Layer & Repository classes •Infrastructure Layer Library classes: JSON, XML-RPC, Web Service classes 119

An Applications Breadth & Depth of Scope •Decide up front a few things: The skill-set of the team • Their understanding of both patterns & domain driven design • Is there seniority? Cost of the learning curve How complex is the project What is the timeline Will the chosen set of patterns and abstraction fit within the given constraints (technical debt) • What can you afford to accomplish now, later? 120

Figure Out Where Things Go •Where do things go? •How do I get them there? 121

Cross Cutting Concerns •Sometimes things don’t always fit into a single layer •Authentication and sessions User object from the domain is persisted in app layer Domain has control of identity and credentials • An adapter/gateway/bridge must be created 122

Technical Issues •Serializability of Chosen User Object 123

Choose The Direction Of The Model •Simple: Active Record • Persistence & business logic combined Or Table Gateway + Row Gateway 124

Choose The Direction Of The Model •Moderate Complexity: Add a layer of abstraction between business & persistence Domain Model Table Gateway + Data Mapper 125

Choose The Direction Of The Model •High complexity & high abstraction between layers Application Service Layer Domain Model Factory & Repository Data Mapper (With Identity Map and Table Gateway) Domain Service Layer 126

Conclusions, Commentary, Summary

Conclusions •Choose a modeling approach that best fits your organization, team, and target project •Know the cost of various approaches, and know what tools and frameworks to invest in 128

Questions? Comments? •Thank you! •Play with the sample project and find me if you have any questions and/or want to know more while at ZendCon 129

Modeling best practices

by Ralph Schindler on Nov 01, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Modeling best practices — Presentation Transcript