In my Symfony2 project, I have a ModelBundle which holds my entities, and other bundles for the frontend, backend, etc, which utilise that ModelBundle.
I have a couple of model-specific functions that perform some entity-specific tasks.
Where do I put these?
Do I create a seperate 'model' folder next to my Entity folder, and
put all those functions in there?
Do I create a controller in my 'ModelBundle' that holds these
functions as actions? This might be weird, since controllers, in my
mind, take HTTP requests and return an HTTP response, so it's not
applicable in this context.
Do I put them inside the entity classes themselves? Is this nice?
And is there a chance that they are over-written when I re-generate
my ORM?
Am I looking for custom repositories? I can make those and put them into a 'model' folder or something. http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#custom-repositories
P.S.: I love Symfony2, but I will be very happy when everyone has a defined set of best practices for the framework :-)
It'd be helpful to know what type of model-specific functions you plan on writing.
If the functionality is for an entity you've already fetched from the database, it belongs in the entity class.
If the functionality has to do with finding an entity or group of entities based on specific criteria, it belongs in a custom repository class.
I'm not a fan of thinking that model classes and entity classes should be different. IMHO, it's an unnecessary level of abstraction.
You're correct in thinking that this functionality doesn't belong in the controller.
If you do go with custom repositories, I suggest keeping them either in an "Entity" folder, or a "Repository" folder. I personally keep mine in "Entity", but that's likely a side effect of having used Doctrine 1 for so long and being used to 'Table' classes.
I hope this helps, but if you have any questions please post some more details of what you hope to accomplish.
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.
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 was looking for models in Symfony2 structure and bundles but there are none.
What is the reason Symfony2 do not have models?
Is MVC the wrong way to go?
I am just curious because I know that CodeIgniter in fact doesn't need to use models too. You can place everything in controllers or even in model in some scenarios ;).
Could somebody explain it more in depth?
That's because Fabien Potencier, the former of Symfony2, does not think Models belongs in Symfony. That's why he called it a HTTP framework instead. See also this article he wrote: "What is Symfony2?"
[...] you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM. Of course, tight integration exists for the most well known ORMs like Doctrine2 and Propel; but they are optional dependencies. The Symfony2 core features do not and will never rely on any ORM.
The Doctrine2 ORM uses repositories to take over the control of mapping databases to a class. If you want to have custom methods in your repository, you can create your own repository. That means that a Repository can be seen as a sort of model.
Because they didn't want to.
Tough answer, but there is no set in stone way to program. There are many different methodologies and you can choose to follow them if you wish, but nobody is making you. In this case, the developers for Symfony2 decided models weren't necessary.
That doesn't mean MVC is wrong. I own a sedan, but if you own an SUV, does that mean you're doing it wrong? Just a different way to get the job done.
Because there are no "models" in proper MVC. Model is a layer. Just like presentation layer (which contains controllers, views and templates).
What you should be looking for instead are: services, mappers and domain objects. Those are the more common parts of model layer.
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.
I'm working on some new software, and I'm trying to make it as modular as possible. I have been coding for a while..but I lack some key principles which I am learning as I go along.
In trying to make my current project modular, I am using the model-view-controller architecture. In designing my application, I have found certain things I am unsure of. So I come to you...
I'll give you some information which may be useful:
I am developing this application in Qt.
It is a desktop application.
Single user, so it is not very complicated
My questions are:
When implementing the various modules(models, views etc..) and all
of the classes associated with them, should I be initializing
modules within modules? Should I create a 'model' instance within a
'controller', or should I create everything in 'MAIN' and simply
pass the modules as references?
My strategy is to separate my application into many MVC bundles.
Each one will follow the basic principles: model gets the data, view
displays it, and controller takes care of all interactions between
model-view, and performs all required logic. Is this correct?
I appreciate all of your help.
Thanks.
Should I create a 'model' instance within a 'controller', or should I create everything in 'MAIN' and simply pass the modules as references?
Pass the modules as references. I don't know if Qt has the concept of packages within a bundle, but in Java, I have separate packages for the model and the view.
My strategy is to separate my application into many MVC bundles. Each one will follow the basic principles: model gets the data, view displays it, and controller takes care of all interactions between model-view, and performs all required logic. Is this correct?
Yes, that's correct MVC principles.
Sometimes in a more complicated application, your application view might consist of the GUI (a view) and a model of the GUI (a model). In this case, the application model, which is probably a database access model, interacts with the GUI model. The controller for both the GUI and the application is driven by the actions of the user.