what could be a good design for layering between the business logic objects and the Database using OOP?
Any of these would work (from Fowler's POEAA):
Data Source Architectural Patterns:
Table Data Gateway: An object that acts as a Gateway to a database table. One instance handles all the rows in the table.
Row Data Gateway: An object that acts as a Gateway to a single record in a data source. There is one instance per row.
Active Record: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
Data Mapper: A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself.
Which to choose depends on which of these you picked (same source):
Domain Logic Patterns:
Transaction Script: Organizes business logic by procedures where each procedure handles a single request from the presentation
Domain Model: An object model of the domain that incorporates both behavior and data
Table Module: A single instance that handles the business logic for all rows in a database table or view.
Service Layer: 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.
In general, the more closely your business objects resemble the DB schema and is centric around CRUD operations, the simpler your Data Source Architectural and Doman Logic pattern can be (it doesnt have to though). If you find yourself with a lot of Impedance Mismatch or with lots of Business Logic not directly related to the DB data, then you might opt for Domain Model / Data Mapper (and might also include an ORM).
There are several approaches you can take with this, but one i'd like to recommend is the DataMapper pattern combined with domain models. See this page for more information.
This way you seperate your data access from your domain models (business logic) in a good and easy way.
If you're a little bit familiar with OOP, the UML model in the page linked above should clarify the way of approach, and how it seperates database logic from business logic.
Related
I have struggled with an MVC concept for a long time in php since I'm not a php developer. I refactored my site several times but it still looks like a cannon pointed in a mosquito. I've read many articles, posts and answears about MVC but it still makes me confused.
Let's have a simple website with articles and comments system. Everything is stored directly in a database (information about articles, paths, comments etc.). Mostly based on this I developed my own app using MVC. Here is how it works:
Controller retrieves data from the database about an article and related comments
It creates required model's objects (current article and comments)
... and then passes necessary data to the View
View presents those data by applying particular templates for provided objects
Everything works like a charm but...
my model's objects don't need any external logic so my domain objects are bordered to getter/setter classes -I'm wondering: do I need domain objects? It's pointless to store separated objects only for getting them from DB and displaying on a website after a while, isn't it?
controller holds a DB connection passed to services and mappers for creating a model's object -but queries stored in mappers can be merged into services functionality
In conclusion, I wonder if it's not a better approach to replace three-part model with a single manager (per object) which will retrieve all necessary data from the database and will pass them in any way and form (i.e. associative array) to the View.
Please do note, that I'm describing a simple case (1:1:1) with tiny logic, where most data retrieved from database are only for a presentation purpose.
Well what you have just described is an architectural pattern for data modelling called the Data Mapper pattern.
In this pattern you separate the persistence logic to a Mapper class and leave all of the Data stuff in The Domain Model. In your scenario you mentioned there is little logic, which is fine. Logic grows as your application matures. The key point is the separation, persistence has nothing to do with logic and therefore should be moved into a different class.
The Mapper class is only concerned with persisting data (generally to whatever data store you choose), in practice you uses "Adapters", which is why in some ORMs you see a different adapter for different data stores (ie. MySQLAdapater vs PostGresAdapater... etc, implementing a abstract Adapter Interface/Base Class).
It should be noted though, in your conclusion what you describe is actually the MVC Architecture.
The Model Layer is essentially your Persistence Layer (like described above)
The View Layer is where you present your data.
Your Controller Layer is where your data manipulation ie On your domain object's data.
Typically a MVC request goes like...
a URI gets mapped to a controller::action
Action gets data, manipulates it and sends it to the view for rendering.
When MVC applications run into trouble is when your Controller accesses several different objects and needs to persist them all. The class architecture of an MVC application tends to be very heavy as the Models typically have more logic on them than in the Data Mapper pattern since MVC models have persistence tied into them (in practice).
Just as an aside, for simple projects like yours, you might want to look into simple presentation frameworks like http://www.slimframework.com/ It has no persistence layer built in, which leaves you to choose the best for your project.
I started some time working with the Yii Framework and I saw some things "do not let me sleep." Here I talk about my doubts about how Yii users use the Active Record.
I saw many people add business rules of the application directly in Active Record, the same generated by Gii. I deeply believe that this is a misinterpretation of what is Active Record and a violation of SRP.
Early on, SRP is easier to apply. ActiveRecord classes handle persistence, associations and not much else. But bit-by-bit, they grow. Objects that are inherently responsible for persistence become the de facto owner of all business logic as well. And a year or two later you have a User class with over 500 lines of code, and hundreds of methods in it’s public interface. Callback hell ensues.
When I talked about it with some people and my view was criticized. But when asked:
And when you need to regenerate your Active Record full of business rules through Gii what do you do? Rewrite? Copy and Paste? That's great, congratulations!
Got an answer, only the silence.
So, I:
What I am currently doing in order to reach a little better architecture is to generate the Active Records in a folder /ar. And inside the /models folder add the Domain Model.
By the way, is the Domain Model who owns the business rules, and is the Domain Model that uses the Active Records to persist and retrieve data, and this is the Data Model.
What do you think of this approach?
If I'm wrong somewhere, please tell me why before criticizing harshly.
Some of the comments on this article are quite helpful:
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
In particular, the idea that your models should grow out of a strictly 'fat model' setup as you need more seems quite wise.
Are you having issues now or mainly trying to plan ahead? This may be hard to plan ahead for and may just need refactoring as you go ...
Edit:
Regarding moveUserToGroup (in your comment below), I could see how having that might bother you. Found this as I was thinking about your question: https://gist.github.com/justinko/2838490 An equivalent setup that you might use for your moveUserToGroup would be a CFormModel subclass. It'll give you the ability to do validations, etc, but could then be more specific to what you're trying to handle (and use multiple AR objects to achieve your objectives instead of just one).
I often use CFormModel to handle forms that have multiple AR objects or forms where I want to do other things.
Sounds like that may be what you're after. More details available here:
http://www.yiiframework.com/doc/guide/1.1/en/form.overview
The definition of Active Record, according to Martin Fowler:
An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.
When you segregate data and behavior you no longer have an Active Record. Two common related patterns are Data Mapper and Table/Row Gateway (this one more related to RDBMS's).
Again, Fowler says:
The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema.
And again:
A Table Data Gateway holds all the SQL for accessing a single table or view: selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database.
A Row Data Gateway gives you objects that look exactly like the record in your record structure but can be accessed with the regular mechanisms of your programming language. All details of data source access are hidden behind this interface.
A Data Mapper is usualy storage independent, the mapper recovers data from the storage and creates mapped objects (Plain-old objects). The mapped object knows absolutely nothing about being stored somewhere else.
As I said, TDG/RDG are more inwardly related to a relational table. TDG object represents the structure of the table and implements all common operations. RGD object contains data related to one single row of the table. Unlike mapped object of Data Mapper, the RDG object has conscience that it is part of a whole, because it references its container TDG.
I have a built an MVC application with a model layer containing entities, data mappers and service classes. So far so good. But now I have a controller that need to show a report containing data from multiple db tables with no relation to any entities in my model. The report is built from a advanced MySQL query containing joins, SUM/AVG-selects. All I want is an array of the data so be shown in the VIEW.
Can I mix methods in my service layer, some that returns entities ("getById()") and some that just returns array of data from my database query ("getAdvancedReport()")?
Is it OK to put the db-queries right in the service layer? If not, where should they go? The data mapper feel wrong because its job is just to map my entites to the db, not to retrieve custom data.
Maybe just "Coding bureaucracy" but i need to do this right.
Cant find anything on the net other than simple CRUD examples of the domain model.
Not really an answer .. more like pontifications with bottle of beer
You seem a bit confused about the point in having data mappers and even about domain object in general.
Data mappers are responsible for the information exchange between storage (which sometimes is an SQL database) and domain object. If you have even a bit normalized DB structure, the database entities and domain objects will not map 1:1. Mappers are made for specific domain object , not for the database tables. A single domain object can even have multiple mappers (for example: one mapper which stores data in DB, and one in session).
If your Report object has no domain logic, you can even use an active record. The pragmatic approach is to use them when the potential domain object has only CRUD with no domain logic. If there is some computation, stick with domain object + data mapper pair.
Service layer is for application logic, not storage logic. There should be no SQL in it. Service should mostly be governing the interaction between undetermined mix of domain objects and mappers. With the exception of mailing services and similar structures.
Also, usually on-line reports are dynamic. You can order the data, filter it and otherwise manipulate. You would end up with a service, which can manipulate the Report object, apply filter to it or extract data from said object. All this tinkering is "application logic".
that's it ... I run out of beer
Can I mix methods in my service layer, some that returns entities ("getById()") and some that just returns array of data from my database query ("getAdvancedReport()")?
Yes, but I would correct your sentence as such: some that returns entities and some that just returns array of data
=> the user of the service doesn't care where the entity/data comes from. So, yes your service can return entities and raw data (array of primitive types).
Is it OK to put the db-queries right in the service layer?
No
If not, where should they go?
In the Repository/DAO. It is OK to perform native queries in the Repository. And the Data Mappers are not used here, simply because we don't need to map entities.
To sum up:
Service->getMyData() > Repository->getMyData() > DB query
Is it OK to put the db-queries right in the service layer? If not,
where should they go?
DB queries should be always placed in data-mapper, because "Service" shouldn't know, where are data from.
I am working on the zend project, I am referring on other zend project to create the new Zend Project.But I don't like to blindly follow that project without understanding. In the Zend Directory structure, In Model class there are mainly two type of classes I see, like as in
- models
- DbTables
- Blog.php //Extends Zend_Db_Table_Abstract
- Blog.php // Contains methods like validate() and save()
- BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b)
Why this specific structure is followed?
Is this is to separate Object class and Database model class?
Please explain.
DataMapper is a design pattern from Patterns of Enterprise Application Architecture.
The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema.
How you store data in a relational database is usually different from how you would structure objects in memory. For instance, an object will have an array with other objects, while in a database, your table will have a foreign key to another table instead. Because of the object-relational impedance mismatch, you use a mediating layer between the domain object and the database. This way, you can evolve both without affecting the other.
Separating the Mapping responsibility in its own layer is also more closely following the Single Responsibility Principle. Your objects dont need to know about the DB logic and vice versa. This gives you greater flexibility when writing your code.
When you dont want to use a Domain Model, you usually dont need DataMapper. If your database tables are simple, you might be better off with a TableModule and TableDataGateway or even just ActiveRecord.
For various other patterns see my answer to
ORM/DAO/DataMapper/ActiveRecord/TableGateway differences? and
http://martinfowler.com/eaaCatalog/index.html
The idea of a Model is to wrap up the logical collection of data inside of your code.
The idea of a DataMapper is to relate this application-level collection of data with how you are storing it.
For a lot of ActiveRecord implementations, the framework does not provide this separation of intent and this can lead to problems. For example, a BlogPost model can wrap up the basic information of a blog post like
title
author
body
date_posted
But maybe you also want to have it contain something like:
number_of_reads
number_of_likes
Now you could store all of this data in a single MySQL table to begin with, but as your blog grows and you become super famous, you find out that your statistics data is taking an awful lot of hits and you want to move it off to a separate database server.
How would you go about migrating those fields of the BlogPost objects off to a different data store without changing your application code?
With the DataMapper, you can modify the way the object is saved to the database(s) and the way it is loaded from the database(s). This lets you tweak the storage mechanism without having to change the actual collection of information that your application relies on.
Put simply about Table Data Gateway (TDG) implementation: you create separate TDG class that contains SQL for CRUD operations with concrete table. So, your models communicate not directly with a datasource (for example database) but via those abstracted ones - TDG classes. So, it's just an approach for making another level of abstraction and it's just a wrapper for communicating with database - get and modify the data. IMHO TDG classes should not contain members, only methods. Here's a good schema that visualizes the use TDG pattern. When using TDG approach, SQL should be moved from model classes to datasource (TDG) classes. And all data that I retrieve from DB through TDG classes are stored in my model members.
Now, what about active record implementation? If I would merge data access and my model class into one model class then would I implement active record? I was unable to find a clear distinction or how those patterns look in PHP and differ from each other.
Often, I'm having one singleton database class and then separate model class for each database table. Each model class has CRUD + several custom (count, avg and etc.) operations. Some classes have members for persisting results from CRUD or custom operations - thats's done upon the need. Could this approach be identified as active record? Also, if I would move SQL from my model classes to TDG classes would this be Table Data Gateway?
From http://martinfowler.com/eaaCatalog/index.html
Table Data Gateway: An object that acts as a Gateway (466) to a database table. One instance handles all the rows in the table.
Active Record: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
The obvious main difference is that TDGs wrap access to a table and only returns row data, while ARs wrap access to a row in the table and adds business logic to it.
Unless you have very low impedance mismatch, having a TDG is preferred because with AR your business/domain objects follow the structure in the database, which us usually not how your domain objects should be modeled. A Row may know how to persist itself, but a Person should not know. It is more maintainable in the long run to to separate persistence logic and domain logic.
Regarding your Singleton DB object have a look at Is there a use-case for singletons with database access in PHP?.