Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Now, im facing three issues about my symfony 2 application architecture using Doctrine 2. This is a one bundle application.
I will use some controllers of course, but I need some special controller "BeforeController" to be called before the others. In the "BeforeController" I want to place some initialize methods. Is it best practice to extends controllers by "BeforeController"?
I want to create some services in ServiceContainer. For every entity which I have, I want to create own service (e.g. There is Products entity, so I will create Product service, which provides methods manipulating with products and so on), if is it good way. Or is it in Controller compentence?
Can somebody explain me, what is in controller or in service competence?
I should like to create some logical and intuitive architecture. Maybe any class diagram should help me.
Can somebody describe me some best practices about it?
From documentation:
kernel.controller Event, and example: Before filters with the kernel.controller Event,
Service: Service base info and more: What is a Service? Controller base info, and additionally Action. It's nothing wrong with creating separate services for each entity if you really need it.
As above.
I recommended this video from SymfonyCon Warsaw 2013 How Kris Writes Symfony Apps.
Hope this help.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have been interested in Laravel Livewire for a few days. But I wonder what is the best way to use it?
I have a website built on controllers. I would now like to add a forum in Livewire.
Should I build a forum traditionally on controllers, and add livewire components to the view to display categories, topics, messages? Does it miss the point and better to skip traditional controllers?
How to name livewire components?
livewire/forum/index.blade.php
livewire/forum/topics/index.blade.php
//
livewire/showForums.blade.php
livewire/showForumTopics.blade.php
I want to stick to some naming convention because as the project grows I don't want it to look chaotic. I will have many more livewire components in the future.
I'm putting this here as it was too long for a comment.
The point of Livewire is to lower the knowledge requirement for creating interactive interfaces, specifically without having to leave the comfort of Laravel. How you choose to implemenent your project (i.e. the choice between full page compoents and single components) is down to you based on the use case. I wouldn't use a full page component if I only wanted to make a single page element interactive.
In your example, you could use either. However, a full page component might make more sense as you will remove the requirement to fire off events to have other components update themselves.
Try and adhere to existing Laravel naming conventions if possible, but most importantly - be consistent with your naming!
I try to keep my components and views in sync with each other, which is also the recommendation on the Livewire documentation.
app/Http/Livewire/Post/Show.php
resources/views/livewire/post/show.blade.php
Take a look at the building a voting app with Livewire series on Laracasts. It might help with your decision making.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Since Symfony 5.1 injecting the Container by autowiring the Psr\Container\ContainerInterface is deprecated see https://symfony.com/doc/current/service_container.html#public-versus-private-services
In case a service still needs access to the Container, does it needs to be injected by hand for the future, or is there another, more convenient, way to inject it?
One option would be to use Autowiring by Name and inject it, whenever there's a variable called $container, however that feels like a hack.
Question: What is the best practice of giving a service access to the container, if it still depends on it in Symfony 5.1+?
Making your services container-aware has been discouraged for quite a while.
As a general rule, you should avoid making your services container-aware and instead directly pass in the required services in the constructor or via setter-injection. In some cases using a container as a service locator can be useful though. For example when you use the AbstractController or when you have a service that takes in a lot of "registered" services, e.g. for handlers/senders in a Message Bus. For those cases Symfony provides a Service Locator/Subscriber: https://symfony.com/doc/current/service_container/service_subscribers_locators.html
The major difference is, that you have to define the services for the locator/subscriber instead of having all services available, like in Symfony's internal container. You can however tag services that should go into your service locator/subscriber and then collect these tagged services, so they will be passed automatically. See: https://symfony.com/doc/current/service_container/tags.html#reference-tagged-services
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I just learned about Laravel Service Containers and it seems like a great functionality.
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
the problem being is that I don't see a proper Use case for this feature, I mean if you have a piece of data or an entity that you're repeatedly using: this can be customized through a model
so when should I use service containers in laravel ?
what are the Pros and cons of this functionality ?
as I understood it prevents us from rewriting 50 controllers when we should modify a commonly used entity or variable throughout the project.
I do not believe you understand it correctly.
Service Containers are just a fancy term that Laravel came up with to describe dependency injection. The major benefit is for unit testing and its biggest competitor is the facade pattern that Laravel also uses. The biggest benefit of dependency injection is that you can mock expectations without requiring additional "scaffolding" code that bootstraps the test. More information about using dependency injection for unit testing: https://medium.com/philipobenito/dependency-injection-as-a-tool-for-testing-902c21c147f1
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There are two main features that I love in Django:
a) It creates the SQL table automatically from the Model
b) It auto generates a powerful admin from the Model
Is there a PHP framework with these two features? I've looked at Symfony and cakePHP, but I couldn't find any info about a)
Thanks!
I heard good things about Laravel, but in principle:
It works in reverse to Django, where its ORM dynamically match your Model's member variables to database tables.
It also has several scaffolding library (example) to generate simple CRUD admin page.
Symfony uses ORM Doctrine that generates database tables based on entity mapping
There is no auto-generated admin dashboard in Symfony2, but there are bundles for that (e.g. SonataAdminBundle)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've seen code written where almost all non-route related code is passed to a model. I have also seen code where all database persistence is handled by a model, but non-DB processing is handled by the controller.
Which is the better approach?
The line between controller and model is actually quite clear.
Model is your application's heart. It contains the business/domain logic required to solve the problem your application was written for. The Model is usually layered into several other layers, e.g. persistence, services, domain, etc. It's a common misconception that the Model is just the database, as much as it is a common misconception that the database should be an ActiveRecord.
The controller (and the view) are part of the presentation layer. A controller's sole responsibility is to receive and handle user input directed towards your application and delegate this to the appropriate parts in the model. Nothing more. It should not handle complex application flow or code of your problem domain. You want controllers to be skinny and models fat with logic. The Model should not know about either C or V and you should be able to swap out V and C for a different presentation layer without having to touch your M.
See MVC Excerpt in Patterns of Enterprise Application Architecture