The right way to implement service level in CodeIgniter applications

Question

Below are two ways to use the service level in CodeIgniter.

1st method

1.send request to the controller 2.calling service layer methods from controller 3.return processed result data set(D1) from service layer to controller 4.then according to that data set controller demand data from model 5.model return data set(D2) to the controller 6.then controller send second data set(D2) to view. 

---

Second method

 1.send request to the controller 2.calling service layer methods from controller 3.service layer demand data from model 4.model send requested data set(d1) to the service layer 5.after some processing return generated data(d2) to controller from service layer 6.then controller send data set(d2) to view. 

---

What is the correct way to implement a service level in CodeIgniter? Besides these two methods, are there any other good ways?

if you can provide an example in code this will be great

Answer 1

Please note that this is not necessarily the right way to do this, but I'm going to explain how the framework can do this, as usual, and then you can learn about other methods and choose the best one for your use case. Therefore, I do not expect this answer to be correct, but I hope that it will give at least a little knowledge about how everything happens, before someone who really knows what they are talking about comes and rings ( also to these people - please feel free to edit / lower this answer: D). Finally, this also has nothing to do with CodeIgniter, but the frameworks in general. Your question should not only be formulated as independent of structure, but also of language.

Therefore, I am going to express my opinion here, and it is the fact that all modern frameworks, especially in PHP, do not support MVC . Why is it important? Because we all need to speak the same language, and mvc does not exist in PHP. It is a fact. Agree to this, and then we can move forward towards adhering to the concept that platforms use; and CodeIgnitor is a particularly good example of the meanness of 'MVC'; henceforth known as "MVC" with quotation marks.

On the plus side, frameworks like Symfony, for example, provide an initial weighted architecture that at least contains some form of consistency in the application, and it looks something like this:

1. A standard HTTP request arrives and gets to the front controller, usually app.php or app_dev.php depending on whether you are in development or production; One includes a lot of caching that needs to be run with every change, and the other is not, which is ideal for development.

2. The router maps the current URL to the controller class and the "action" (method) in this class.

3. Part of the implementation of the framework dependencies finds out what objects are needed for everything from the controller to the model level and vice versa, and either creates instances or prepares to create them when necessary.

4. The controller is created with any necessary dependencies and the corresponding method is executed. Usually you start your development and “connect your code” to the framework.

5. Here you choose your architecture, but the most important thing both from the point of view of the developer and from the point of view of the business (to reduce maintenance costs in the future) is consistency.

6. I personally prefer that my code be separate from the framework. I pass the scalars taken from the request to the application level service, which uses objects from the model level (passed through DI) to use domain objects. The fact is that domain objects are not transferred directly to the controller, they are proxied through the application level environment, so you can theoretically replace the entire infrastructure surrounding it, and yet, all you need to do is transfer these scalars to this level before they get to the model level and everything works (think about CLI calls, there are no more controllers).

7. Application-level service uses any necessary Repositories , Services etc. (And passes these scalars to them, remember the separation?) That execute business logic (usually this is where your design patterns come into play on a day to day basis.), And then return this data to the application-level service.

8. The service then returns the data to the controller and guess what? This is where frames tend to screw up! Because in the modern framework there is no concept of "view". There is only a template, and you transfer this data to the template and send it. So, in your diagram there is absolutely no concept of representation, because this is not how everything is done. And to be honest, I still use templates because it’s the fastest way to do something, but until modern frameworks get together and start using Views, we’re out of luck, and we must remain persistent when faced with the fact that some (like Laravel) call themselves mvc frameworks.

Please note that Fabien Potencier explicitly states that Symfony was not an MVC framework - at least he knows what he is talking about. Again, this is not a purist, it is important that we all speak the same, actually the right language in computer technology.

So, since you like charts so much, here's how some can do it with today's frameworks ...

This is for an application that has a Review and Criteria concept for each Review . And don’t even start me with Symfony forms, they are so connected to everything that they are not a serious part of any architecture.

How many layered layers do you need? We already have "MVC", in DDD we have the concept of separating "Application", "Domain" and "Infrastructure", so first these two groups work together, and then this "level of service"? Do you really need another layer, or is the above enough? Things to think about ...

You see, you are not stuck with a framework / http request to launch the application as a result of this separation.

See the "services" in the above diagram? They are separate from the controller, so you can drop the scalars from anywhere, and the application will still work. I think this will give you the necessary separation . It’s great to do things right, learn how to do it, and then learn how to control yourself and be pragmatic when it comes to business, and this is necessary, but frameworks need to figure out their things - and you certainly don’t You will write beautiful code with CodeIgniter;)

Answer 2

IMHO there is nothing or nothing:

option # 1 - If you want to reuse the service level in several controllers / actions and submit data from different models based on the request, it makes sense to go to the first one.

option 2 # . However, the first option may be problematic if your data model is more complex. What if a second model call is required based on the data of the first call? Using a controller for this business logic does not meet the entire purpose of the service level. In this case, it is better to go to the second.

I think the second one is more common.

Answer 3

Dependency launch and adapter template will be a good place to run. CodeIgniter does not support any of them, so you will need to write a wrapper or possibly a hook.

Your view could only support xml | html, since json had to be pre-mapped to a .json file and then returned as output, but it would have to be done using code, it’s easier to just return the object in this case and changed it on the interface. PHP is an embedded language that works with (xml | html)

A service model works best when it is injected (dependency injection) into a controller / model and specified as a property of this controller / model.

Then the service binds to the interface

For example, facebook / twitter Both of them have a request and response function, but both adhere to similar patterns, but have different endpoints.

 interface SocialMediaAdapter{ public request(url); public response(); } 

---

 public class FaceBookProvider implements SocialMediaAdapter { public request(url){ } public response(){ } 

}

 public class TwitterProvider implements SocialMediaAdapter { public request(url){ } public response(){ } } 

---

 public class SocialMediaServiceProvider{ protected $provider = null; public function constructor(SocialMediaAdapter $provider){ $this->provider = $provider; } public function fetch($url){ return $this->provider->request($url); } } 

Dependency Injection Required

 new MyController( new SocialMediaServiceProvider ( new FacebookService ) ) 

Answer 4

You must use the first one. Since an MVC web application uses a controller to branch your business logic from a view, this is a bit of a gateway. You need to start processing information using the controller, from the controller you must call the model or service level, or anything you need, and finally, you must return the data to any other source from here. Your presentation or service level should not directly access the model.