I am in trouble to choose the right way to develop my application.
My app will be quite complex and I would like it to be well architectured.
I will have in fact 4 "applications" (adminAPI, clientAPI, frontWebsite, adminArea) and I want each of these "applications" to run on a different server in production.
So my first idea was to create 4 symfony projects. But I have to share a lot of code about entities, forms, validators, buisness logic.
So I see that I can create only one project with one different AppKernel per application. This sound good to me.
Is it the right solution?
If I go for it, should I create also one Bundle per AppKernel to keep things clean and one "CoreBundle" with shared classes like entities, forms, managers and handlers?
Or it is better as said on Symfony Best Practices to keep all in one AppBundle?
As you see I'm a bit confused and I really need your help to create a professionnal application that will grow quickly.
Thank you for your time.
You must not create one project for each area of your application.
With Symfony2 your are to create more than one development environment.
You can create for each of you area one bundle and just decide within the kernel witch bundle should be loaded depends on the environment you have chose.
I would create a "CoreBundle" with all the shared functionality and then use it in the 4 Symfony projects.
Related
I have a long list of models in frontend. Some of these have functions that are required to be run in batch. For this console is fine.
I can include the models by copying over the code, however this is not a decent approach.
What Im looking for a way to import models from the frontend submodule in console command so I can make changes in one place.
To clarify,
the standard way of including
use app\models\Mymodelname;
in the console\model results in the following error
'Class 'app\models\Mymodelname' not found'
use app\models\Mymodelname;
Have not worked with this include statement before. I prefer to use the frontend/backend as is. If I had to make a wild guess though, this looks for models within console. #app is an alias for current application.
Usually, I keep anything used by more than 1 application under common. As you pointed out, maintaining two copies of the same code is not a good practice.
Try using frontend\models\Mymodelname directly if moving to common is not an option
I don't know if you have two separate applications, or could benefit from this, as you are already using submodules, but depending on your desire to separate concerns with some console commands this might be advantageous.
If you are using composer to manage your dependencies then you can create a separate repository in git, for example, and add a new dependency in your project which contains these common models.
Then, include your dependency in both projects. This introduces some troubles while developing since both apps share this dependency and it can be frustrating at times; I have shared common functionality between multiple interval laravel projects in this fashion with great success.
Currently you seem to be using submodules so this might require restructuring which could be difficult or impossible.
Another option if you want to keep to submodules is to keep common models at a higher level (not inside a submodule) so that you can import the models into both submodules and use them in both places. I shared common models between modules with yii 1.1.16 using this strategy over several years with much success.
Both options have their advantages so weigh carefully your desired outcomes. Feel free to ask for clarification.
How to add private github repository as Composer dependency
#app is an alias of current running application. It can be frontend or backend or console. If you want to access model across applications, add it to commen\models. Or change app\models to frontend\models. That way, you can access frontend models on console. Better way is moving it to common\models.
I am developing web application using the laravel. I would like to 'package' some of the functions, which is re-usable. For example, I got a UserController, with database setup, and view, etc. The UserController is expected to re-use in most of the web development in the future, but some UserController may have different behavior, for example, some application's user may have a field rewardPoint, some may not. But they all have some similar behaviors, for example: register, login, forgetPassword, etc. So, can I package out a common UserController with all the basic database setup into one file or script to reduce the development work load? Thanks.
You've hit the nail on the head already - since your requirements are likely to change between projects you will struggle to create a single solution that works everywhere. You have a few options, including:
Copy the useful classes from your last project and update them to fit.
Create a package or bundle of base classes that include common and reusable code, then extend these into your project and modify the extensions as needed.
Attempt to create a "one solution for all" that you can drop in to all of your projects.
I would steer away from 3; it's likely to add the most bloat for the least gain. 1 is useful whilst you get used to the framework, especially if you tend not to revisit old projects; over time you will refine your code and develop patterns of work. Eventually you will probably end up doing 2; you can store these in git, use bundles or composer packages, and you can continue to improve them over time.
I'm studying the Laravel 3, 1 week ago, but didn't understand everything about the routes.
My main question is: how to create administrative routes?
In the video lessons from Jeffrey Way (Tuts Premium), I could understand two things about it:
Nested Controllers (/application/controllers/admin/user.php)
Bundles (/bundles/user.php) - He did not say much about it.
Anyway, I noticed 2 things (obvious):
On both sides, I can have a route / admin / whatever.
But what the correct way?
I'm really very confused.
Laravel bundles are for developing modular code that you can reuse from application to application in Laravel. The Bundle itself is very much the same as the 'application' directory you have as standard in a Laravel install, allowing you to create modular sub applications within your project. I highly recommend you avoid bundles for the moment entirely and focus on learning the core functionality of Laravel.
For your needs, place your routes within your routes.php file within the application directory and nest them to your hearts content. This will serve your purposes fine. If you're not building/using bundles, you don't need to use bundle routes.
When you're comfortable with Laravels routing and you've built one or two apps you may well have an idea for a bundle that will help you develop your apps faster in the future. This is the time to start learning about bundle routing as it's the only way to link your application logic with your bundle and provide it with a URL schema.
Hope that helps.
Neither way is really right or wrong, the beauty of Laravel is that there are so many ways to achieve the same thing so it's up to the developer to choose what works for them.
Personally I started by using nested controllers as they're much easier to get up and running. I would however recommend making the move to bundles. If you plan on sticking with Laravel (and you should) then it would make sense to build a bundle that includes the auth and components you use in each project already setup. That way you just need install the bundle and you're good to go.
I have an application which is developed in Symfony2. Now the structure for it is as follows:
FrontBundle - includes everything related to the application's view and UI.
PersistanceBundle - includes everything related to the persistence layer of the application.
DomainBundle - includes everything related to the entities of the application and the services.
Is this structure ok? Or bundles are used like forum feature - ForumBundle - which includes every layer (controllers, services, domain logic and persistence) related to the forum.
There are no hard and fast rules on how to structure your app using bundles, but here's what I came to after developing on Symfony2 for close to a year.
Use one app specific bundle. At first, I started with multiple bundles like CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle, etc. That proved to be not so convenient in the end, so I switched to just one app specific bundle — AppBundle.
You can organize your code neatly using subnamespaces. For example, the backend controllers would go to the AppBundle\Controller\Backend subnamespace.
Note that I'm talking about one app specific bundle — that stuff that's unique to the concrete app and won't make sense to reuse elsewhere. You can still develop separate bundles for reusable stuff and put them into the vendors infrastructure.
Keep non Symfony specific stuff out of bundles. There is no need to have a bundle for the model and the Service Layer classes in a bundle if they are not Symfony2 specific. See this question and my answer for further details.
Like Elnur said, use one AppBundle is a good practice.
A single bundle implements the MVC pattern himself so i think it's not a good idea to use bundles to separate your layers.
I think the best way to use bundles is to think "open source". If the feature you are developping is enough generic to be released for everyone, or to be reused in a future project, place this feature in a bundle.
This way will force you to build the feature without any business rule which belong in your AppBundle.
Bundles are bricks
There are different ways to organise application structure for your projects. But if you want to distribute your bundles and follow symfony best practices, then bundles are more features than separation of UI. More about bundles read in documentation.
I have two projects with the following structures, both valid I think:
making a bundle for each feature: BlogBundle, StoreBundle and so on,
and AppBundle that contains general stuff. No Backend/Frontend
separation. It's SaaS where backend is frontend in most cases.
One bundle for frontend, one for backend. They share only entities
and domain specific stuff. The application has two different ends.
I'm starting to familiarize myself with using the module-based architecture for zend framework projects. My real reason behind being interested in the module architecture is to be able to take a module from one project and just drop it into another project. Maybe I'm not getting it right..
But what I'm noticing right off the bat is that controllers within each module cannot have the same name as any other controller in the main application (or in any other module, though I haven't tested this). This leads me to think that modules are not really independent self-contained units, so I wonder how this affects their ease of distribution from one project to another.
The other issue is what if I were to take a module and drop it into another project. Do I have to update the .zfproject.xml manually? and wouldn't that be a bit too cumbersome to be done manually?
Maybe I'm not clear on how modules should be used in zend, so I'd like to know when you decide it's best to use them, and when do you decide not to use them, or do you use them all the time, or do you never use them?
I always used module based architecture so far in my projects, because I like to separate concepts. For example I have always an ADMIN module whose classes and controllers dont mix with the rest of the application. Using modules you can reuse modules for other applications, for example if you create a BLOG module.
The names of your controllers will be something like Admin_IndexController for the admin module even if the file is named IndexController.php.
Another concept that is nice and help you reuse resources is the plugins. Use them for authentication or to check validity of the requests.
You need to setup namespaces for your modules so that they are easily moved into a new project without renaming.
If you are using Zend Tool then you will have to edit the zfproject.xml. I haven't spent a lot of time using this so I'm not sure if there is another way without manually editing.