I don't get it how it really works.
I have a database table user and a model User:
<?php
class User extends Zend_Db_Table_Abstract {
protected $_name = 'users';
}
And in the controller I call it: $user = new User()
But how do I get for example all users or a user with the id: 1?
Zend_Db_Table implements the Table Gateway pattern and the associated Zend_Db_Table_Row implements the Row Data Gateway pattern.
This means that as the table class represents your database table, it makes more sense to use a plural class name. Similarly, a singular class name should be used for the row class.
Hence you end up with something like this:
class Model_Users extends Zend_Db_Table_Abstract
{
protected $_name = 'users'; // database table name
protected $_rowClass = 'Model_User'; // row class name
public function fetchAllInLastNameOrder()
{
return $this->fetchAll(null, array('last_name', 'first_name'));
}
public function fetchUserById($id)
{
return $this->_fetchRow('id = '. (int)$id);
}
}
class Model_User extends Zend_Db_Table_Row_Abstract
{
public function getFullName()
{
return trim($this->title . ' '
. $this->first_name . ' '
. $this->last_name);
}
}
The point of creating your own classes is that you can add your own methods that your controllers and views can then use. You should never use the Zend_Db_Table methods directly other than in your model classes. This is because this model design is tightly coupled to the database implentation. Over time, you may find that this isn't flexible enough and want to use a different system. If you have ensured that the rest of your application only ever accesses methods created in Model_Users and Model_User then you should be able to reimplement your model without breaking the rest of your app...
For larger applications and ones with complex business logic, it is rare for a model to be a simple wrapper over a single database table. For better flexibility and maintainability, you can consider creating models which are simple classes and then using a mapper class that maps from the model to the database. This is explored by Matthew Weier O'Phinney in his talk Architecting Your Models, which I highly recommend looking at.
Also, for ideas on how to use the model from within the controller, the Quick Start or my tutorial are good starting points.
Are you looking for $user->find()?
Also, Zend_Db_Table != Model. You can read more about the M of MVC here:
Model Infrastructure
Zend Framework: Surviving the Deep End
Writing Robust PHP Backends with Zend Framework
Try creating a static method in your User class that returns an array of all users.
Related
I have a Parent Class Model Like this:
namespace vendor\appname\core;
class Model
{
protected $db;
protected $session;
protected $cookie;
protected $record;
public function __construct()
{
$this->db = new Db;
$this->session = new Session;
$this->cookie = new Cookie;
$this->record = new Record;
}
}
here I have my child models where i can extend the base model and use there objects
namespace vendor\appname\models;
use vendor\appname\core;
class Login extends Model
{
// here i can use simply like so
$this->db->prepare() // and so on
$this->session->set() // and so on so fourth
}
So if i have 100 class should i do the same thing "object composition " is this a good practice ??? what about the registry pattern or factory ? is it possible to implement it here ? or dependency injection
Based on your question, i think you should probably read and research more about the first five OO design principle (SOLID) and General Responsibility Assignment Software Principle (GRASP) to understand more about design pattern and object creation.
Having said that, what you are doing is more of inheritance instead of composition. To make it simple,
Inheritance is more of an "is-a" relationship, for example a UserModel "is-a" Model, thus all properties and methods of a Model will be part of a UserModel.
Aggregation is more like "uses-a" relationship. A Model "uses-a" QueryBuilder and DatabaseClient.
Composition on the other hand, is more like "has-a" or "contain-a" relationship for instance, Book "contain-a" Page.
This is just an example in hope of making things a bit clear for you. Having understanding in these and also Solid and Grasp would make you understand about various design patterns available.
I'm reworking a project on Laravel 5.1
What I realize is that the old classes have become much complicated and do not really follow the 'single responsibility' principle anymore.
So I'm planning to do such:
<?php
class User extends Model
{
}
class SocialUser extends User
{
}
So I have a few questions,
Is it possible to achieve that?
If yes, then does the SocialUser class link back to the same database table which is Users and would it conflict with the User model itself?
Is this all a good design practice at the first place? Or I better make use of traits?
Thank you.
What you’re doing (extending the User model) is perfectly fine, and an approach I use myself in projects.
For example, if an application I’m building has shop-like functionality, then I may create a Customer model that extends my User model, and contains say, order-related relations:
class Customer extends User
{
public function orders()
{
return $this->hasMany(Order::class, 'customer_id');
}
public function worth()
{
return $this->orders()->sum(function ($order) {
return $order->total();
});
}
}
In a recent project, I’ve been working on email campaign functionality and created a Recipient class that extends the User model to add campaign-related methods:
class Recipient extends User
{
public function campaigns()
{
return $this->belongsToMany(Campaign::class, 'recipient_id');
}
}
Because both of these classes extend the User model, I get all of those (and Eloquent) methods:
$customers = Customer::with('orders')->get();
So long as you set the table in your base User model, any classes that inherit it will use that same table, even though the model may be named differently (i.e. Customer, Recipient, Student etc).
IMHO I would go for the Repository pattern. It make's a lot of sense in your situation.
I would do the following:
interface UserRepository {
public function find($id);
public function getAll();
public function create(array $attributes);
public function destroy($id);
//you get the point
}
class CoreUserRepository implements UserRepository
{
//implement the interface rules
}
class SocialUserRepository extends CoreUserRepository
{
//implement the specific logic related to a SocialUser
}
Update
As Mjh described in the comments simply implementing the interface on all UserTypeRepository caused repetition - probably not what you want!
By extending your CoreUser you avoid repetition & maintain a design that will work for your situation.
Although, in your case it could be argued that you are still following SRP because everything in the User model is relating to a user, it's only the type of user which is differing.
Why go for the Repository Pattern?
You are ensuring you have a contractual agreement that all User
Repositories need to implement.
Code is easier to maintain.
Business and data access logic can be tested separately
Should you extend your User model?
Here you are in danger of model pollution. While you can do anything with a model - not everything is a good idea.
Defining relationships on this approach would be a headache due to the confusion caused.
I want to write discrete framework agnostic models.
I wrote interfaces for all of these models.
The problem is when implementing these interfaces, for example with Eloquent I'm linking all my business logic into the ORM.
For example I want a method addVariation on a Product model.
The Interface
interface ProductInterface
{
/**
* Adds a variation
*
* #param VariationInterface $variation
*/
public function addVariation(VariationInterface $variation);
// ...
}
The Concretion
class Product extends Model
{
/**
* #param Collection | VariationInterface
*/
protected $variations;
public function addVariation(VarientInterface $varient)
{
if( ! $this->hasVariation($varient) )
{
$this->variations->add($variations);
}
return $this;
}
}
The problem I have is all my business logic lives in my specific Eloquent ORM implementation of my model.
How could I possibly separate this out? The only real dependancy I can see is I need a collection class of some type? or maybe I can just use plain old arrays?
I just dont want to link all my logic into a specific ORM I want to remain framework agnostic.
Just remove all your logic from the Eloquent ORM.
You only need an ORM to make saving and retrieving data from a database easier. You should write all your business logic with plain old php objects. You can then create some general PersistenceGateway interface that all your business logic models use e.g.
interface PersistenceGatway {
public function saveGatewayData($id, array $data);
public function retrieveGatewayData($id)
}
Your decoupled business logic uses this interface to save and retrieve data. Then all you need to do is implement the interface with your ORM of choice (or you may need to also create some adaptor class to help you). You can now plugin any ORM you like, so long as it implements the PersistenceGateway interface.
Take a look at Uncle Bobs Clean Architecture. Web frameworks like Laravel should be a plugin to your app/business logic, not the other way around.
Edit: Very basic example.
class SomeBusinessLogic {
// Note: Class depends on the PersistenceGateway. Any class
// that implements this interface can be passed in. This is
// essentially how you decouple logic from ORMS. You can now
// implement this interface with any ORM you like and pass it in
public __construct(PersistenceGateway $gateway){
$this->gateway = $gateway;
}
public function someLogicMethod($id){
// do something and save state to the gateway
$this->gateway->saveGatewayData($id, ['some_state'=>'value']);
}
public function someDataReturnMethod($id){
return $this->gateway->retrieveGatewayData($id);
}
}
// Im extending from Eloquent here, but you can do a similar thing
// with any ORM.
class SomeEloquentModel extends Eloquent implements PersistenceGateway {
public function saveGatewayData($id, array $data){
$model = $this->find($id);
// call eloquent save method
$model->save($data);
}
public function retrieveGatewayData($id){
// retrieve the data. Important to return
// an array NOT an eloquent model, otherwise
// we are still coupled. I think toArray() is
// the correct method to call on eloquent model
return $this->find($id)->toArray();
}
}
class SomeController {
class someControllerMethod {
// Your controller decides on the implementation of PersistenGateway
// to use. You could also use an IoC container which would be a slightly
// cleaner solution
$logic = new SomeBusinessLogic(new SomeEloquentModel());
$logic->someLogicMethod(Input::get('id'));
return $logic->someDataReturnMethod(Input::get('id'));
}
}
Everytime I'm writing a Laravel model it just gives me a feeling of messy code. I have relationships and other model functions specially when using domain driven design. So I though about separating relationships and functions.
Example I have a User class that extends Eloqeunt:
class User extends Eloquent{}
and inside this class I have register functions and password hashing functions etc. Also, we can declare the relationships so:
class User extends Eloquent{
function post(){
return $this->hasMany('POST');
}
}
For some reason this smells funky to me. My solution was to create a Entities folder and inside create a User folder which will hold 2 files one would be UserRelationship which would hold of the the relationships for this class:
class UserRelationship extends Eloquent{
function post(){
return $this->hasMany('POST');
}
}
and a second which would be the actual User class where I would write all of the functions and this class would extend the UserRelationship class instead of Eloquent:
class User extends UserRelationship{
public static function register($email, $password, $activate_token)
{
$user = new static(compact('email', 'password', 'activate_token'));
$user->raise(new UserWasRegistered($user));
return $user;
}
}
What do you guys think of this approach I am relatively new to all this so I don't know if this is bad practice or to much work for little reward. What do you guys recommend?
For a user model, it is too much work. The easiest way and still a better approach is to define the relationship in the user model. If for example it is a post model where you have relationships for post to "user, comment, reply etc" then you can attempt splitting your relationships
Here's the basic premise, I'm using an active record pattern for db objects, and I think I need some direction how to organize these classes. And also in general how I could potentially split up my class structure. Hopefully I don't explain this too terribly. If composition pattern is the way to go I may need a little hand holding on a way to implement it.
Let's say there's the ActiveRecord base class, at the bottom of the totem pole that deals with mapping objects to the db and the db to objects.
A child of ActiveRecord is a sort of generic User class, that deals with user sessions, logins, encryption of the password field on save and such.
Another child of ActiveRecord is a ActiveRecordButSlightlyMoreAdvanced class. Usually this class has nothing to do with User, but here's my issue.
I want to have a subclass that wants to be essentially a combination of User and ActiveRecordButSlightlyMoreAdvanced; UserButSlightlyMoreAdvanced, without having to copy paste all of the methods from User. It doesn't make sense for User to extend ActiveRecordButSlightlyMoreAdvanced, as it'd require essentially overriding a bunch of methods that have undesirable behavior for User.
It would make sense for UserButSlightlyMoreAdvanced to extend ActiveRecordButSlightlyMoreAdvanced, but I'd have to copy and paste a bunch of methods from User.
I know some people think better with pictures, so here's the structure illustrated.
Base
class ActiveRecord
{
....
}
Child
class User extends ActiveRecord
{
....
}
Also Child
class ActiveRecordButSlightlyMoreAdvanced extends ActiveRecord
{
....
}
The Problem
class UserButSlightlyMoreAdvanced extends User AND ActiveRecordButSlightlyMoreAdvanced
{
:( :( :(
}
I've been thinking about this problem for about a month now and cannot think of a solution that doesn't place burden of maintaining the objects dually if there's a change to how one of them implements saving. I'm going to experiment with a few solutions over the next couple of days and possibly post what I think was best in this situation.
My guess is that you meant to say this:
class UserButSlightlyMoreAdvanced extends User AND ActiveRecordButSlightlyMoreAdvanced
{
:) :) :)
}
If that is the case, look into traits http://php.net/manual/en/language.oop5.traits.php
You might try using the strategy pattern. In this case you would create your class:
class UserButSlightlyMoreAdvanced extends ActiveRecord implements ActiveRecordButSlightlyMoreAdvancedStrategy
{
private $_strategy;
public function useStrategy(ActiveRecordButSlightlyMoreAdvancedStrategy $s) {
$this->_strategy = $s;
}
}
and make your strategy class:
interface ActiveRecordButSlightlyMoreAdvancedStrategy
{
// Define what this should do here
}
Make a strategy class that implements the above interface.
class ActiveRecordButSlightlyMoreAdvanced implements ActiveRecordButSlightlyMoreAdvancedStrategry {
// Do stuff here
}
Now when you call those advanced methods, both classes implement the same interface, but the UserButSlightlyMoreAdvanced class just passes the requests through to the strategy object:
class UserButSlightlyMoreAdvanced extends ActiveRecord implements ActiveRecordButSlightlyMoreAdvancedStrategy
{
private $_strategy;
public function useStrategy(ActiveRecordButSlightlyMoreAdvancedStrategy $s) {
$this->_strategy = $s;
}
public function someSlightlyMoreAdvancedFunction () {
return $this->_strategy->someSlightlyMoreAdvancedFunction():
}
}
Hope that helps.