Figure 1 - Model-View-Controller combined with the 3 Tier Architecture
In his book Domain Driven Design, Eric Evans creates a classification of the different kinds of domain objects that you're likely to run into. I would like to show you how I have enhanced his original description from my experience after having built an open source PHP framework for developing web-based enterprise applications.
Here are the original descriptions:
| Entities | An object whose job is to hold state and associated behavior. The state (data) can be persisted to and retrieved from a database. Examples of this might be Account, Product or User.
Entities are based on nouns. |
| Services | An object which performs an operation. It encapsulates an activity but has no encapsulated state (that is, it is stateless). Examples of Services could include a parser, an authenticator, a validator or a transformer (such as transforming raw data into HTML, CSV or PDF).
Services are based on verbs. |
| Value objects | An object whose responsibility is mainly holding state but may have some behavior. While some languages use primitive data types which are containers for nothing but values, there are others which hold these values in objects which contain methods which are suitable for that data type. Examples of Value Objects might be Color, Temperature, Price and Size.
PHP does not support value objects, so I do not use them. I have written more on the topic in Value objects are worthless. |
This is a simplistic diagram of the structure of the RADICORE framework:
Figure 1 - Model-View-Controller combined with the 3 Tier Architecture
Note that each of the boxes in the above diagram is a hyperlink which will take you to a more detailed description.
The responsibilities of each of these components are as follows:
| Controllers | These are services. They exist only in the Presentation layer. Each is responsible for translating a request into one or more calls on one or more methods in one or more Models.
In my framework there is a separate reusable Controller for each Transaction Pattern. |
| Models | These are entities. They exist only in the Business/Domain layer. Each is responsible for the business rules for a specific entity (database table).
In my framework each database table has its own concrete table class which inherits from the same abstract table class. This provides all the standard boilerplate code which which is common to all database tables while custom logic which is specific to individual Models can be inserted into any of the available "hook" methods. |
| Views | These are services. They exist only in the Presentation layer. Each is responsible for extracting the application data from one or more Models and transforming it into the format required by the client.
In my framework there is a different version for the production of HTML, CSV and PDF. Each Controller can communicate with no more than one View. |
| DAOs | These are services. They exist only in the Data Access layer. Each is responsible for generating and executing the SQL queries for a particular DBMS.
In my framework there is a different version for each supported DBMS, currently MySQL, PostgreSQL, Oracle and SQL Server. This allows me to switch the entire application from one DBMS to another by changing a single line in the configuration file. |
Note that Controllers, Views and DAOs are reusable components which are built into the framework. Models have to be generated by the developer using facilities provided within the Data Dictionary. Each table class is initially built from a standard template which inherits all its common code from an abstract table class which is also built into the framework.
Some people say that objects also have an identity which is described as follows:
In object-oriented programming, analysis and design, object identity is the fundamental property of every object that it is distinct from other objects. Objects have identity - are distinct - even when they are otherwise indistinguishable, i.e. equal. In this way, object identity is closely related to the philosophical meaning.
Consequences of identity
Identity is the basis for polymorphism in object-oriented programming.
If having an identity is a fundamental property of every object then when and how is it created? How do you query an object's identity? How can it be the basis for polymorphism when it is never mentioned when an object is referenced in a polymorphic manner.
I suspect that this idea was created for compiled languages where objects can exist in memory for long periods of time and you may wish to reference an object which was created hours earlier. This is irrelevant in PHP because each PHP script starts with no memory, and anything stored in memory during its execution is automatically lost when the script terminates. This is a characteristic of its "shared nothing" architecture.
In my framework I can communicate with any Model without knowing its alleged identity. Each Model is tied to a database table and can deal with any number of rows from that table, and each row has its own unique and immutable identity in the form of its primary key. I have no need for any other type of "identity".