What structure and how to structure it [Various services, structure and validation]?

Question

Ok, so I'm trying to understand some of these patterns.

Well, that’s why I am encoding the application in CodeIgniter, which should be able to send data about the machine and the client to different types of companies using SOAP, possibly XML, separated by commas, etc.

But they all need the same thing.

I want to make it as dynamic as possible and make sure that it easily records tests.

Thus, the service should take a couple of things:

• handler
• applicants [1-2]
• PARAMS
• an object

I started to create different classes

Gr8Exp NordCar SwePerf

each implementing iServiceRequest interface

interface iServiceRequest{ /** * Send the request to the company server. */ function sendRequest(); /** * Saves the response into the database. */ function saveResponse(); /** * Prepares the request to the company, setting info from form and shit. */ function prepareRequest(); /** * Soap, XML, CSV, JSON * @param type $method */ function setRequestHandler(iServiceRequestHandler $handler); } 

Then they need to structure the Soap, XML, CSV, JSON request depending on which handler I inserted.

After those who needed to pass validation (not all), I used:

 interface iAdaptServiceRequest{ /** * Structure the array information and put it into an object structure in the right place. */ function structure(array $info); /** * Make all the checks for the function */ function validateInfo(); } 

But I'm stuck, it worked very well when I just used a SOAP request; but now. Since I need to format them differently, use a different handler for each type of request or company, I don’t know what to do. I could put them in different folders and recreate the class in different folders. But this is not a good practice, since I duplicate the code throughout.

In the end, I want to run the chain as follows:

$ result = $ m-> prepareRequest () → sendRequest () → saveResponse ();

Any suggestions

Answer 1

IMHO:

- create / use the front controller.

- The front controller determines which request handler to use (JSON, SOAP, XML, etc.).

- The request handler generates a common "Request" object, which behaves the same for all interfaces, basically placing the variables in a common named format inside the "Request" object

- determines which service sends the request and sends the request object there

- The service processes the request object and generates a response object

- The controller creates the appropriate (JSON / SOAP / XML) View object to process the response object into the correct view type, and the view displays your response as that type.

Answer 2

I would use something like yours: $result = $m->prepareRequest('JSON')->sendRequest()->saveResponse(); , but determining which data format I am sending.

The prepareRequest(string $type) method will check the format and call another method to convert your data to the appropriate format.

Something like that:

 function prepareRequest(string $type){ if ($type == 'json'){ $this->convert2json(); } if ($type == 'xml'){ $this->convert2xml(); } // And so on } 

Answer 3

Often an error occurs in the MVC or Observer pattern. This is not a situation in which this pattern is applicable. In the MVC template, the view and model are related to each other. The view must update itself based on the information of the object. A good example is the presentation and base tables in a database. This is not what you want here.

The design pattern that is appropriate for this problem is the Builder pattern. The Builder template consists of four interacting clusters: 1. Builder, 2. ReaderManager, 3. Converter, and 4. DataObject. ReaderManager uses an interpreter pattern. Conversion can be performed using a state template. What is the result of ReaderManager (some DataObject) - this is the input for ConversionManager. This can be done using an abstract class instead of an interface (my preference is for data-oriented classes). Builder connects ReaderManager using ConverterManager and takes care of data transfer.

A few years ago I wrote about design patterns. The builder pattern was one of the patterns I described, and this is a link to this page: http://www.loekbergman.nl/InsideArchitecture/TheProcess/DesignPatterns/Builder It shows the UML diagram of the pattern. In the following link you can download the jar with examples of design patterns. One of them is a builder template: http://www.loekbergman.nl/InsideArchitecture/DownloadsAndLicense I wrote this code several years ago, so I give you this code without warranty. (Is that the right term in this context?) In the code, you can see the folder with the name specifications. This is another example of an interpreter pattern. (The Builder template, of course, also has an example of this template).

To fill out the link to the MVC template: http://www.loekbergman.nl/InsideArchitecture/TheProcess/DesignPatterns/Observer and the interpreter template: http://www.loekbergman.nl/InsideArchitecture/TheProcess/DesignPatterns/Interpreter