In my project I have API Bundle and Dashboard Bundle where I reuse Entities like Client, User, Store etc in both bundles. All entities are in API Bundle at the moment, however I have a feeling that they should be stored in a different Bundle, something like Generic Bundle.
Does anyone has a Best Practice for that?
I read this question about relationships, but it speaks about relationships and not Best Practice.
Thanks.
I don't think there is really one best practice here but the key is re-usability. Let's say down the road for some reason you decide to run the API & Dashboard as 2 separate services. Having a UserBundle with your Client & User Entities means you'll just need to install that on both services along with either the API or Dashboard bundle. You could then also have a service with only your UserBundle that handles the login, ect... Same thing for the Store, I would personally decouple that as much as I could.
But the real question is if it is necessary ? Would you reuse that UserBundle in another project ? Do you plan on splitting the project as services down the road ?
Ultimately the specifics are really up to you, a GenericBundle could be all you need or you might have enough to separate into UserBundle & StoreBundle for example.
Related
Actually I have five simple projects based on Symfony 2.0. Each project has user management using Doctrine ORM.
Among bundles, User class has very few differences. Bundle1 may add "business name" attribute, Bundle2 may add "inbound communications" relationship. But all share the same well known attributes like "salt", "password", "username", "roles" and so on. And of course some logic for searching users.
Question is what's a reasonable approach to unify the user management? I mean creating a reusable UserBundle. I'm looking for some advice about xml configuration, mapped super classes, services, entity and forms inheritance.
I've looked at FOSUserBundle, it looks a bit complicated for me. I can't fully understand its logic. I don't need templates and views because each of my five bundles handles that. And I prefer to code it by myself.
I've looked at FOSUserBundle, it looks a bit complicated for me. I can't fully understand its logic. I don't need templates and views because each of my five bundles handles that. And I prefer to code it by myself.
You're answering your question yourself, embedding the pros and cons.
Pros:
Reusable code makes development faster
Cons:
Reusable code is often more generic and lead to more complicated things to solve problems.
If you're working in a team which often develop projects involving an User Management, then it is totally valuable to make your own.
Most of the released bundles were initially developed for personal use.
If you know you're not gonna work with anything else than Doctrine2 you can bypass the part abstracting the thing to make it work with MongoDb for example.
If you do so, keep in mind that it will be shared amongst other developers while being used by co-workers which use the same technology as you do.
If you're alone, make it fit your needs.
Couple of month ago I got a legacy project written on Sf2. I fixed some bugs, and added some new functionality, but still i feel that it was made a little bit clumsy. Well, maybe not just a little :) So, I have a number of questions, how things really should be done in Sf2.
The first thing which is bothering me, is that the Application is separated on Frontend and Backend bundles. The're standing on the same model, and for example entity Book can be seen from FrontendBundle and edited from BackendBundle. In some way this is producing a confusion of abstractions. So my question is - is it right, or wrong, and if wrong how it should be done in appropriate way?
Bundles are components in symfony2 that provides a functionality to your app. The frontend and backend approach has changed in symfony2, the bundles are used instead.
For example, you can create a BookBundle, and put all the functionality regarding to books in that bundle, adding, updating etc. And by configuring the routes, you can redirect all the requests about the book to that bundle.
The main point is, the frontend and the backend about the books resides in same bundle, and only in that bundle(with controllers and entities and repositories and views etc.).
This is the intended usage in symfony2.
I'm developing a SaaS where tenants are both real ones and admins (us). So "fornt-end" and "back-end" are the same. Anyway, according to many other questions bundles are a way to structure your project in reusable way.
I really don't think that our bundles are going to be reused, but i still need a way to split the project into bundles to quickly find files we want to work on. Application should:
CRUD for customers - tenants should be able to manage their
customers/partnerships
CRUD for customers tags and keywords (a way to categorize their customers)
CRUD for broadcast notifications sent by us (a messaging system)
CRUD for tenants - we should be able to manage our tenants
So, how can organize my bundles? Could be:
CoreBundle: only Doctrine2 models
ResourcesBundle: templates, js, css, images
SystemUserBundle: manage tenants and customers CRUD
MessagingBundle: message system
How this design can be improved?
According to the Symfony2 documentation:
In Symfony2, a bundle is like a plugin, except that all of the code in
your application will live inside a bundle. A bundle is nothing more
than a directory that houses everything related to a specific feature,
including PHP classes, configuration, and even stylesheets and
Javascript files (see The Bundle System).
Personally, following this description, I would set up the SystemUserBundle to contain the Doctrine2 model and templates/js/css/images that specifically relate to managing customers, rather than splitting them out into CoreBundle and ResourceBundle. However, splitting your app into SystemUserBundle and MessagingBundle sounds like a reasonable approach.
I like to think of it this way - does the bundle encapsulate some behaviour that I might need or want to plugin to a future Symfony project(s) I am involved in. Customer Management, for example, is something that might apply to any app and be re-used across projects (indeed, this is why the extensible FOSUserBundle exists).
I don't think the Symfony2 docs go into sufficient detail on bundles (yet!) but in case you haven't found all the relevant sections these are the ones I'm aware of:
Symfony 2 Page creation
Symfony 2 The Bundle System
Symfony 2 Bundles best practices
I'm currently trying to figure out the best way to implement doctrine persisted Role entities as a M2M relationship compatible with FOSUserBundle. Previously I was using just strings with the default implementation and was persisting it with a doctrine array mapping.
Now I need to have roles as seperate entites as we want to build an admin backend where others can grant users roles.
Basically, it's a pain in the ass. The FOS interfaces are built for string representations, not Role entities. Change the implementation, you break a lot of stuff i.e. FOS commands to promote users. And it's hard to figure out exactly which pieces of the interfaces are needed to allow the symfony2 security system to continue working correctly.
I could rewrite the role management code and use Role entities as much as possible, e.g.:
$user->addRole(new Role('ROLE_FOO'));
But that breaks commands and possibly existing code?
Or continue using:
$user->addRole('ROLE_FOO');
And couple role/entity manager code in addRole() (bad design).
I've noticed this is a grey area (Role entities with FOS) and has been mentioned on the symfony2 boards and round here, but no decent solutions.
Anyone had any experience or can think of a decent solution?
I decided to go with a mix of an array/ArrayCollection implementation. I tried to follow the existing interfaces as much as possible so as not to break the security system. I have documented my solution at http://blog.jmoz.co.uk/symfony2-fosuserbundle-role-entities
I'm developing and intranet application with symfony2. I'm currently using only one fat bundle for all my features. Seem like this is what is recommended and what most symfony2 developpers do.
I wonder how you deal with an growing application where you create entities again and again. Do you just create them in your Entitiy directory inside your bundle? Do you sort them into subdirectories?
The same question can me applied to others classes like the forms.
Any advice on this?
In my opinion, even if best practices say to use a single bundle, for big project this can make you lose time.
In my projects I'm used to create :
- one bundle for statics pages and resources : for example PagesBundle
- one bundle to the member area : UserBundle
- One bundle for the core of the application : ArticlesBundle in the case of a blog, for example.
This serves to separate and save time in the tree Symfony2.
Tell me what you think.
This is a very subjective topic and mostly relies on what you are most comfortable with. The reason why the best practice now proposes just one big bundle is that the bundle approach was mainly for reusability purposes.
Some people even recommend to store entities outside of any bundle in src\YourNamespace\Entity.
Either way: subdirectories are definitely a very valuable option to sort classes.