We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. MVC

Thinking of MVC...

I want to share my thoughts on the implementation of the MVC in Phalcon.

Class Phalcon\Mvc\Model represents the implementation of ActiveRecord (ORM). But the model in the MVC pattern is not necessary and not only is DAO (Data Access Object), and also contains the business logic. On the basis of these considerations I have two questions:

  1. Where to describe the business logic? In the child class Phalcon\Mvc\Model?
  2. Where describe the model did not contain the DAO (no persistent data)? For example: a model for interaction with any third-party service through the API, or some complex business logic, which is enough to store temporary data in files or memory (Phalcon\Mvc\Model tuned for relational databases), or do not require storing data in external repositories.

I imagine the implementation of the model in the MVC-frameworks like this: There is an abstract class Model, which describes the basic behavior of model in framework (DI, error handling or something like that). And in the same class DataModel (provisional name), extended the class Model, which in turn is able to work with external storage. In such a case, if you need a model with no storage, you must inherit from the class Model, and if necessary to work with data storage - DataModel.

P.S. Sorry if I'm somewhere not accurately described the specifics of Phalcon, I just started to learn it.

3


98.9k

Maybe the name Phalcon\Mvc\Model leads to this confusion, a good name would be Phalcon\ORM\Model or Phalcon\Mvc\ActiveRecord, and those classes child of Phalcon\Mvc\Model are intended to describe business logic.

You can setup your classes under a namespace such as MyApp\Models and extend those that interact with relational databases from Phalcon\Mvc\Model and others without a class or classes/components intended for that.



1.6k

can't agree more~ so... Will Phalcon have something like DataMapper or anything advanced? My boss is asking us to separate "Business Logic" & "Data Access" all the time...



6.9k

Yeah @ironlion model is actually an acttive record its not good but it is the "de facto" standard ... i use to make model wrappers making "easy" persistence changes. Having the advantage of define my own custom querys and common actions. I think its a good solution cause i have my middleware api consistent. Finally i think a good designed applicatio its framework agnostic (as possible).



1.6k

i implement as the following


//Business Logic Layer 
namespace fishjerky\models;
class User extends \Phalcon\Mvc\Model{ 
      function doSomeBusinessLogic(){ //ex. getMyFriends()
             $users = \fishjerky\dao\UserDao::getUsers($uid);
      }
}

//Data Access Layer
namespace fishjerky\models\dao;
class UserDao{
   public static function getUsers($uid){
          return \fishjerky\models\User::query('ex: select friends of this uid');   
   }
}```
any advice?