I am trying to understand the concepts of the service containers and service providers in Laravel.
At this moment, my application consists of (custom generated) models, views and controllers. So, pretty straightforward.
But now, I am planning to build a cron job which will fetch some data from an external service. This data needs to be stored in my database. I also have a view where users can manually enter the same sort of data. My controller validates the input and saves the model.
However, I don't want to copy the logic of the store function in my controller and I also don't want to call that same function from another controller.
So, I read about service providers. I followed some tutorials and read the docs on laravel.com but I somehow don't get it.
For example, I have two models: "Order" and "OrderEntry". Currently, the only function within these models is a relationship function so I can call $order->entries() and $entry->order().
Like I said I have a OrderController which validates some things and the stores a "Order" with $order->save() in the store method of the OrderController.
What's the best approach for this? I can also write a store function on the model "Order" itself. That way I can also use the same logic on different places in my app.
An ALTERNATE option to service providers and maybe not the end-all-be-all:
I had a requirement for uploading and parsing files, where the user can do it through the UI, but a dev also needs to process files manually. I used a command to be able to call it from the controller or from the CLI. Perhaps not as extensible as service providers, but a slightly simpler option. They are particularly easy to call & run from a cron job too.
If you're decided on service providers, they're unfortunately a little fuzzy for me as well. I guess maybe consider the scale of what you want to do, and the reusability of the service provider you're creating. This post helped me "get it" a little more, but I have not yet had a scenario where this has been needed. Good luck!
Related
I am looking to add multiple API's to my senior project on an MVC based framework (Laravel). I understand the basic concept of MVC, but want to make sure that I am doing things according to best practice.
Basically, I am going to have a class/function that takes a query and calls that query on a Amazon's Product API. I have seen an example of calling API's from directly within the Controller on Laravel (see http://www.phplab.info/categories/laravel/consume-external-api-from-laravel-5-using-guzzle-http-client).
Perhaps I don't understand MVC well enough. Should an external API call be in it's own class? And if so, should it be a Controller Class or a Model Class? I hope the Stack Overflow gurus can enlighten me. Let me know if I need to clarify anything!
It depends to what you want to process with external API.
If it's a part of the business, it can be in Model (lot of people put
the business inside the model to follow the encapsulation principle
of OOP).
If it's the explicit process, it should be in Controller
(like most people do).
For example, if you have a model Transaction in bank transfer (that automatically convert the currency, it needs the external API to get the exchange rate), the external API call should be wrapped in model. So controller cannot modify the Transaction object and it will be safe.
In another hand, you can call to external API in controller, do some extra stuffs then set it back to Transaction object. It's also good because model always contains only properties. It makes application also clear enough.
They are 2 ways of use, none is absolutely right or wrong. But if you choose one, follow it, don't mix.
Another, both 2 are only ok. The better way is putting the external calls to other places (modules etc), then call it by single line in model or controller.
I want to build a Laravel application which users both web and API parts. The common (and mine as well) question is whether to use separate controllers or not.
There are 2 options:
Separate controllers
Laravel API controller structure?
Use one controller and check the request type (is Ajax, or depending on the request link) and return either JSON or HTML.
Laravel resource controllers for both API and non-API use
Those who have the 1-st opinion doesn't explain the DRY problem solution - web and API controllers would be the same except the return statement (JSON or HTML view). But since most post recommend to separate controllers I suspect I don't understand something about the DRY problem solution.
I don't see any disadvantage of the second method. But people say something like
If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.
Please explain me the DRY problem solution for the first approach (separate controllers) and the possible underwater rocks in the second approach (single controller)
Please explain which approach is preferable.
I think this is a great question, and I too am keen to see the responses.
I can see the arguments for both approaches. I however would create and maintain separate controllers, whilst using services to share common logic between the controllers where it is known that this will never change.
For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers.
The reason for this approach in my mind, is that the web and API logic may diverge and it would therefore be easier to iterate each without impacting the other.
If this is unlikely, then I would still create separate routes, but point them both at the same controllers, so that if it did change in the future, you can simply re-point the API routes to their own controllers.
Where should the authorization code in Laravel? We have a lot of options and a lot of plugins to manage this situation but and I'm not really sure where I should put all logic. Let's see:
I know that there are a lot of possibilities with a correct result but I want to know which is the optimal solution for you or know your techniques in this situations.
Imagine we have a help desk application done in vuejs and Laravel as API, so we have users, groups, roles, permissions. And maybe a user will only able to see its tickets.
Should we do a TicketPolicy with view, update, create methods? Maybe should we use repositories? Maybe a is_user_allowed method in Ticket's model?
Should we use middleware in routes files and do something like Route::get('tickets/{ticket}', 'TicketsController#show')->middleware('can:show')? Or should we call $this->authorize($ticket) in show, edit, update and store methods of the controller?
Or maybe should we use FormRequest#authorize method and then use something like $user->authorize('show', $ticket)?
What if we want groups or roles? Should we use some plugin like Entrust and/or policies?
What do you think, what do you do?
Best place I found to put classes that group specific logic that do not fit in standard MVC pattern is completely new folder for Laravel. I name mine Services, probably because I read it somewhere. One of the great things in Laravel (and probably other modern frameworks) is flexibility, you can just pop a folder, add a new namespace and have it contain whatever you need.
As for your example, I would implement a class App\Services\Permissions that would contain all necessary logic for accessing different resources in your application. Then call it's methods wherever you need them, be it Requests, Middlewares or Eloquent Models.
I am developing for learning purposes my very first "big" Spring MVC project. I am learning everything by myself (and of course, thanks to this amazing community).
What I am starting to wonder is... Is my design "correct/valid"? So far I am creating one Controller per View/Page specially because of the ModelAttributes (attached to the method).
Is that fine? Should I start doing it in some other way? Are there "offical" patterns in this matter?
To start, I assume you are creating a web project based on your use of ModelAttribute. You want to follow the MVC (Model, View, Controller) convention. The "Model" is the data you are manipulating. This data should be retrieved via a service layer. Then, your controller should call your service methods to get the data, making your controllers completely agnostic of your data. This is nice because you are free to change your data structure, e.g. migrating from MySQL to MongoDB, without worrying about changing your controller, all you need to change is your service layer. Also, this allows for controllers to use many different services in certain instances. Your controller receives requests from the client, e.g. the website user's page requests, GET/POST requests, etc., and performs some action, usually fetching/updating data via the service layer, and then returns a view. Each controller can take many requests, and can render many views. It is good practice to break up controllers by function. For example, if you had two different sections for your website, one for Admins, and one for Guests, then you may want to use one controller to process the Admin requests, and another to process the Guest requests. Each of these controllers can handle all requests from Admins/Guests accordingly. You may be a bit confused about controllers. Each method in a controller is bound to a single request/view, but a controller may have many such methods.
As you are learning, I would suggest exploring some client-side mvc frameworks like AngularJS. Angular allows very easy data binding and manipulation options, and makes it pretty easy to create RESTful web services.
I have an application that handles licence registrations for various product. I'm currently re-factoring into a basic MVC framework (not using any of the big ones yet). We have various basic scenario's e.g. someone can make a cc purchase of a product via the website. This fires the create customer, create order, create licence etc objects (basically just db inserts using beans and gateways as I think that is the "standard"?).
Anyway, to handle all this I'm calling a purchaseService.cfc, which validates the various business rules and wraps the persistence(db) layer processes together. That seems to work fine and I thought having a purchaseService cfc contained that process well.
Now we need another, similar process where a key can be "registered" to achieve the same as above. i.e. provide a licence to the customer. (obviously there will be differing rules).
As far as naming conventions go, are there any rules to help decide what to call these service "wrapper" type cfc's. Most of the examples I see are per object, e.g. the user object has a userGateway and userService and don't give examples of cases where we need a wrapper to call multiple objects. Is what I've done ok convention wise using a purchaseService object? (I was going to call it CustomerlicenceOrder.cfc based on the other objects it was dependent on. What will I do with the new requirement? Perhaps create another service object? Called PurchaseByKeyService? Doesn't sound right to me. I have read so much on OO and MVC etc etc but the more I read the more questions I have :)
Thanks
There's certainly nothing wrong with grouping actions into a common service. In fact, it's usually more accepted than just creating standalone services for each domain object.
Read more on the Service Layer pattern if you're interested.