Model Scope in C#

Decoder Data Matrix ECC200 in C# Model Scope

It s often hard to draw a line between what goes into a model and what goes into a controller For example, in the banking example described earlier, one might well argue that the validation related to amounts and locations should be in the controller, rather than in the model In general, though, the developer community has largely adopted the fat model, skinny controller approach recommended by various thought leaders, including Martin

Fowler, Jamis Buck, and Chris Hartjes (you ll find links at the end of this chapter), which proposes that business logic should be located within models, rather than controllers, wherever possible This approach offers a number of benefits:

Fat models reduce duplication and help developers adhere to the Don t Repeat Yourself (DRY) maxim by encapsulating key business rules into reusable objects and object methods Inheritance chains can then be used to apply these rules consistently across the application Specifying models using OOP principles also makes it possible to extend base models with additional functionality as needed, and to make a distinction between public and private model attributes within the larger application space Self-contained fat models that encapsulate all the business rules necessary for their proper functioning are more portable than thin models that rely on application controllers to enforce business rules Since most of the application s business logic is in the model, rather than in the controller, switching to a different framework, for example, becomes much easier, as the model can simply be swapped in to the new system and will usually work without significant retrofitting required When fat models handle most of the heavy lifting, controllers typically end up containing only a few lines of highly focused code This makes them easier to understand and read, and contributes to better overall performance (because controllers are typically invoked more frequently than models) It also produces more maintainable code: For example, if you need to change the business rules for a particular application entity, you only need to update the model for that entity, not for all the controllers that use it Debugging and testing become more transparent under the fat model, skinny controller approach, because it s usually very easy to identify whether the model or the controller is the source of an error, and to correct it with minimal impact on the rest of the application

It s important to note, at this point, that the Zend Framework does not come with a Zend_Model component, or a set of predefined models, that you can drop in to your

Q: A:

Is a model simply a set of prepackaged SQL statements No, definitely not It s a common misconception that models are simply object representations of database tables, with methods corresponding to the SQL INSERT, SELECT, UPDATE, and DELETE statements In reality, models are much more than Structured Query Language (SQL) wrappers They can (and should) enforce applicationspecific business rules, perform calculations, handle conversions, apply filters, and perform any other required operations on data Remember, the more intelligent your models, the less work for your controllers, and the more maintainable and portable your application

4:

application; you always need to create your own The Zend Framework includes a number of tools that can assist you in this task, such as the Zend_Db_Adapter database abstraction layer and the Zend_Db_Table interface to table operations However, you can also create your application models using third-party tools like Doctrine or Propel, and integrate them into your Zend Framework application And that, in fact, is what the next section is all about

While you can certainly create your application models from scratch, using the components provided by the Zend Framework, there s an easier way: use an Object Relational Mapping (ORM) tool to automatically generate them for you These tools can automatically scan an existing database and create model classes corresponding to the tables within it, using either the ActiveRecord or DataMapper pattern It s then a simple task to add these autogenerated models to an application and extend them as needed to support specific requirements There are a large number of free, open-source ORM tools available for PHP, such as Propel, Doctrine, RedBean, and Qcodo This book uses Doctrine, which is extremely popular among developers on account of its ease of use, flexibility, and extensive documentation The Doctrine package includes a database abstraction layer, with support for most common RDBMS systems; a customized version of SQL called Doctrine Query Language (DQL); and tools to automatically generate model classes from an existing database schema These model classes are based on the ActiveRecord pattern, and are fully compliant with the PHP 53x object model To get started with Doctrine, download and install the latest version to your development environment by visiting the official Doctrine Web site and getting a copy of the most recent release of the software Then, extract its contents to a temporary area on the file system