Model

The model is an object that represents the (abstract) information that should be returned to the browser. In fact it is not so simple in terms of business logic. So, let’s try to understand it.

Models are stored in the system or in an external database in a persistent state. Looking from the controller side, regardless of model, you are accessing a database for information wanted for the HTTP response. Once the information has been left in a persistent state in the database you will be able to get a model, with the information, for passing to view.

There is a tendency that when you write directly to SQL to access the database, the coding can in some cases become complicated, and difficult to read. This is even truer if the DB schema becomes complicated. In order to mitigate this is difficulty, TreeFrog is equipped with an O/R mapping system (named SqlObject).

In the Web application, CRUD (create, read, update, delete) is a function of minimum requirements; the SQL statement you write is almost routine. For this part, the O/R mapping system will function particularly effectively.

I think that with many Web frameworks, the way the model object itself (to be referred to as the ORM object) is the object for O/R mapping is to be recommended. The default on TreeFrog Framework is for the model object to have a relationship that includes the ORM object.

 "Model has ORM object(s)."

Doing it this way, which was one of the reasons why I wanted to compact the O / R mapping system itself,  is beneficial in a number of ways;

  • Intuitive structure of the ORM class.
     
  • Possible to conceal the information that is not required to show the controller side.
     
  • Can absorb  both logical delete and physical delete of the record as the model.
     → Use this page to create a deletion flag column, it is then only necessary to update it in the model remove () method.
     
  • Since there is no need for a relationship table since the model is one-to-one, the degree of freedom in design model class is greater
     → Business logic can be added to the model in a natural way.

The disadvantage is that the amount of code increases a bit.

  In brief: Hide unnecessary information for controller and view.

 

API of Model

In general, when classes are more independent they are also more reusable. It would therefore be desirable to design dependency of the model to be as small as possible.

In Web applications, the DB is often used for data to persist, so that "model class" relates to "table".  For those Web applications that handle many kinds of data we accordingly create many tables (models). Because it is common when designing a DB schema to conduct data normalization, models will have a relationship with each other through their properties (fields).

When coding the class of models, the following conventions are used. These should be learnt.

  • use the texport() method to be exportable (it is possible to pass to the view).
    → This is equal to be able to set to the QVariant type (by setValue() possible), it is a class with the following.
     
     - A public default constructor
     - A public copy constructor
     - A public destructor
     - Declaration in Q_DECLARE_METATYPE macro (At the end of the header per file)
     
    Please see the Qt documentation If you want to know more.

 ★ Model that is generated by the generator command meets them.
 
 
The model class that was created in the generator is inherited from the TAbstractModel class. A convenient method to handle the ORM objects is mounted on this; I have inherited it in order to take advantage of its features. That is, the inheritance is merely for the function reuse. In models that do not access the database, the inheritance is therefore not necessary.

  In Brief: if you want to use an ORM object you should use TAbstractModel class inherit regardless.

When the model is created by the generator, the getter/setter of each property and the class methods that are equivalent to "create" and "read" are defined.  The following example is an excerpt of the Blog class which we made in the tutorial chapter.

  static Blog create(const QString &title, const QString &body);
  static Blog create(const QVariantMap &values);
  static Blog get(int id);    ← Get the model object with a specified ID
  static Blog get(int id, int lockRevision);
  static QList<Blog> getAll();
      ← Get all model objects

When you run the create() method, the content is stored in the database at the same time as the creation of objects.

Let's also look at the methods defined in TAbstractModel class.

 virtual bool create();   // New
 virtual bool save();     // Save (New or Updated)
 virtual bool update();   // Update
 virtual bool remove();  // Remove
 virtual bool isNull() const;   // Whether present in the DB
 virtual bool isNew() const;    // Whether before saving to DB
 virtual bool isSaved() const;  // Whether stored in the DB
 void setProperties(const QVariantMap &properties);

 
The save() method internally calls the create() method if the ORM object does not already exist, or the update() method if it does exist. So, if you don’t want to distinguish between the method and the create() and update() method then you can simply use the save() method to call the model.

The code generated here is only the tip of the iceberg.  You can add  or modify the property, that is needed to be hid, by shifting from protected to private or something you like.

Creating a Model with a Different Name to the Table Name

When you create a model generator command, the model name comes from the table name, in the format  '_' (underscore).
If you want to give the individual a different name with this format, you can run the command with the string at the end, as follows.

 $ tspawn  model  blog_entries  BlogEntry    ← only model created

 $ tspawn  s  blog_entries  BlogEntry   ←  model-view-controller created

   

Creating original model

You do not necessarily have to associate a model in the table. It can also be used to summarize relevant data in the case of passing information to the view.

If you want to create a model on its own without the use of a generator, you should declare a class as shown in the following example. Save in the models directory, add files to the project (models.pro), and specify the file name of the source and header. Run, to make the rest.

class T_MODEL_EXPORT Post
{
  public:
    // include default constructor, copy constructor, destructor
    // write the code freely afterward.
};

Q_DECLARE_METATYPE(Post)    ←  charm to pass to view
Q_DECLARE_METATYPE(QList<Post>)  ← charm to pass the list to view

 
 

Comments are closed.