Openbiz implementation of PHP metadata programming

Introduction

The idea of metadata (Metadata) programming originates from the high-level language of Java, which simply separates the business logic from the implementation code, describes the mapping relationship between the services in a descriptive language such as XML, and does not need to write implementation code to complete programming.

meta-data programming features from Java

The original data is one of the most advanced technologies in software architecture, allowing you to write less code to achieve more things, and to maximize the reusability of business logic. It may sound abstract, let's look at a practical example to help you understand the metadata programming idea I'm advocating.

openbiz Architecture makes it possible for PHP to program Meta data

For script-level PHP language, it has become one of the mainstream languages of web development. But since his birth was a process-oriented programming language (I'm talking about php3, with shovels), it's not a language like Python or ruby that comes up as the ultimate object-oriented language for objects.

Based on this simple background, and perhaps the reason that PHP itself is free of open source, we see that the advanced extensions for the PHP language always lag behind the commercial languages of. Net, Java, and objective C. When PHP5 released, he shouted, "Dude, it's now an object-oriented!" "Java,. NET and cocoa asked him, "Do you have meta data programming concepts?" Do you have UI-level reusable controls? Why haven't Zend put your clothes on? Go back and play with the shovel.

The development route of the Zend framework is always enthusiastic about the reuse of the underlying logic code, such as Zend_cache, Zend_mail, Zend_gdata, zend_table does achieve a lot of low-level logic reuse and solves many delicate and complex problems.

Here we actively recognize the contribution made by Zend, but "Big Brother you go a step more forward Ah!" ", No! Our eldest brother likes to do menial work, do not like to engage in literature and art.

Finally special humor, after Zend unremitting efforts, eldest brother finally put a complex thing (PHP) abstract for another complex thing (Zend Framework). Your Zend API interface is not much simpler than the extension of PHP itself.

Here I have to mention the University of Illinois graduate master brilliant student, former Motorola technical director, Chinese-American Rocky Swen, (I have always been a follower of his technical thinking), as early as 2003, PhP4 that era, he proposed to let PHP based on metadata, without writing code is to achieve the concept of programming , and has the embryonic form of the openbiz framework, after 9 years of perfect to today.

The idea was just to brighten my eyes, you see Zend, codeigniter,cakephp the inheritance framework is equivalent to a set of reusable code libraries, and the openbiz framework is unique in that it is an interpretive framework, equivalent to the role of "compiler". When other development environments and frameworks are dedicated to getting developers to write less code, brother Rocky, don't let them write code. The direct use of simple XML language to describe the mapping relationship is complete programming.

Let's compare these procedures.

An example of an order-managed data Object

PHP's traditional data object writing

Class Orderdo

{

protected $m _id;

protected $m _client;

protected $m _product;

protected $m _price;

protected $m _timestamp;

Public Function Create () {...}

Public Function Delete () {...}

Public Function Update () {...}

Public Function Search () {...}

Public Function list () {...}

}

PHP based on Openbiz's metadata notation

<?xmlversion= "1.0" standalone="No"?>

<bizdataobjname="Orderdo" class="bizdataobj" dbname= "Default" table="Order" idgeneration= "Identity" cachelifetime="7200" >

<BizFieldList>

<bizfieldname="id " column="id" type="number"/>

<bizfieldname="Client " column="client" type="Text"/>

<bizfieldname="Product " column="Product" type="Text"/>

<bizfieldname=" price" column="price" type="number"/>

<bizfieldname="timestamp" column="timestamp" type="DateTime"/>

</BizFieldList>

</BizDataObj>

That's great! This gives me a glimpse of two possibilities for the future, and if the main work of programming is done based on a descriptive XML language, then there is a great chance that there will be an entirely visible, programmatic approach.

Another extreme may be the object factory concept mentioned below, which automates programming.

Object Factory concept, a program that can write programs!

Every time I mention this concept, I'm thrilled, as if we were just a few yards away from intelligent programming. The idea, as far as I know, is that. NET's introspection (the Chinese translation is very strange) this concept, that is, the main program dynamically create another independent subroutine, dynamic compilation, and then load and destroy on demand (like Transformers), I was very excited to see, then this concept is basically no one to mention.

Until later, I read it. Openbiz's underlying source code surprisingly discovers the idea of an object factory based on PHP implementation. Analyze the idea, take the data object as an example:

The xml-based metadata file is considered a "factory" assembly list, which describes how to "assemble" the object, and the mapping relationship between this object and the Stratigraphic database, and the mapping of other objects at the same level (e.g. One-to-many ORM).

After the object factory has created the production instructions for such an object, it creates and assembles the desired objects as described, and caches the object body and state in the system in a serialized fashion, optimizing performance for triggering the call again. Until the metadata configuration file changes, the object needs to be dynamically produced only once, that is, unlimited use.

Based on this programming logic, we solve a common problem of modification and extension.

For example: Customers will often be the project acceptance of the bottom layer data field changes, "You see the contact management of this module, can add a birthday and preference fields, otherwise this end of the paragraph I am afraid ...".

What to do?

Change it. Additions and deletions (CRUD), column (list), search (searching) one can not be less all to change.

Who changed?

You must change, because you write the program.

Openbiz metadata is not the same, now I only modify a data description file, then the object factory will detect changes in the metadata configuration file, and then he will automatically rewrite the object and all its associated mapping call (ORM).

When you are faced with a particularly complex system of business coupling, you will find that these top-level objects "You have me, I have you" stack call is extremely complex (disgusting). For example, in the document modification record view also calls the contact person's these several fields and so on, you are sure to be able to make the correct change all over again with this data structure each corner?

This inhuman force can also! But the object factory can, because it is on demand production creation.

The PHP language itself has such a flaw in the processing of objects that the lifetime of the object cannot be across views, and when a page request is executed, all resources associated with it are automatically destroyed and recycled. In particular, data objects are objects that typically have database links and cursor state.

The openbiz session management mechanism fits into the state of the object that can be persisted to the implementation of the factory.

The object factory invokes the Metaobject::setsessiondata () interface of the abstract class to automatically restore the object state before the object is delivered.

So that when we write the program, we can cross view to invoke the data that the user has entered during the entire user session. For example, the information that the user has entered is displayed as the default value on the current view.

Example of calling syntax in PHP:

$defaultValue =

Bizsystem::getobject ("Package.do.DataObjName")

->getactiverecord ()

->fieldname;

Syntax examples of simpleexpression through openbiz in meta data

<element ...

Defaultvalue= "{@package. Do.dataobjname[fieldname]. Value} "

/>

Not only describes the data map, but also describes the business logic based on openbiz metadata

If you are already interested in this meta data programming approach, please continue to look down.

The correlation mapping between the data object and the data table can be meta data, what else can be metadata?

The three-tier architecture of MVC, the UI can also be metadata, and the UI-level elements of view and form can also describe loading and triggering relationships through an XML language, such as

Which form should this view load?

Which field of the data object should the text control on this edit form be bound to?

Which of the classes should be triggered when this button is pressed?

We imagine additions and deletions (CRUD) These common logic framework can be realized, if my demand is when the customer after the order, automatically send mail to notify me, and send text messages to inform the Distribution department. Such a relatively complex business logic, how metadata implementation?

data object triggers and configurable plug-in services

The trigger for this email and SMS should not be implemented at the UI level, as we should consider triggering the logic of sending mail regardless of where the order is generated. So the business logic should be coupled to the data object, that is, the logic should be triggered whenever an order is generated.

And the common reusable logic of sending and sending messages and texting can be defined as pluginservice, for example, in the Mail service, the recipient, the title, the content should be the API parameters, and the email account, the SMTP server information is usually not much changed relative to the entire system of the business, As a metadata interface, and how to send a message with a server link is the object logic of the concrete reuse. The subtleties of this design will be analyzed in the next article.

To implement the logic just now, I just need to create a

Orderdo_trigger.xml metadata File

<pluginservicename= "orderdo_trigger " description= "package=" "class=" Dotriggerservice "bizobjectname="Collab.order.do.OrderDO">

<dotriggertriggertype="INSERT" >

<triggerconditionexpression= "" extrasearchrule= "" />

<TriggerActions>

<triggeractionaction="Callservice" immediate="Y" delayminutes=" repeatminutes= "">

<actionargumentname= "Service" value="Service.lib.userEmailService" />

<actionargumentname= "Method" value="SendEmail" />

<actionargumentname="Recipientemail" value="{@profile: Email}" />

<actionargumentname= "emailtemplate " value="Orderconfirmemail" />

</TriggerAction>

</TriggerActions>

</DOTrigger>

</PluginService>

When the "INSERT" event occurs, invoke the Send mail service, the recipient is the user's mailbox, the message content template is Orderconfirmemail

So far, a line of code has not been written to describe the typical business logic in metadata. With the traditional development approach, to deal with such problems, 150 lines of code work overhead is how to avoid. And readability is not necessarily so clear.

Speaking of here, I too like openbiz this bird (I mean his logo), feel like a php inserted on the wings.

Now we phper can say to Java, PHP now can describe business logic, you Java is nothing but data mapping and configuration information.

Comparison of openbiz metadata programming and Zend naming rules matching programming

This article introduces the openbiz of this kind of metadata thought is not unique, if simply on the abstraction of the data object, there is also a kind of advanced mode that must be mentioned, called the naming rule matching pattern. This is also an extension of Java. Translated into PHP implementation methods, such as:

$obj = new Stddataobj ($tableName);

$obj->name= ' ABC ';

$obj->attribute_1 = 123;

$obj->attribute_2 = 456;

$obj->save ();

I don't need to define the structure of this object before using it, but create it as needed, anyway, when I save the data, let it automatically match the database. However, it seems that the extensibility of this logic is limited to data logic, and the extension logic also needs to use the traditional definition declaration way.

It is important that you do not release the main work of the developer from the code.

This article takes the Openbiz framework as an example, let us see another possibility of programming.

From how to simplify the code, to the extreme as far as possible not to write code, but only to describe the business logic.

This is the essence of maximizing reuse in object-oriented thinking.