I started using and testing Symfony 4 for main project migration. I was used to getting told by Symfony on how files should be structured, but now when there are no more bundles, I wonder, how to structure huge monolith application.
Scale now: ~300 routes, ~70 controllers, ~90 entities, ~20 bundles
How services.yaml should look like? - should I stay on App namespace or maybe I could simulate bundles? Where to put service configuration for each component?
How services and controllers should be separated in directories? - Should I go for src/Service/{Something}/{Something}Manager.php or stay on src/{Something}/Service/{Something}Manager.php and just don't use Bundle keyword? Why?
Where would you put UserAuthenticationProvider and/or WebSocketServer?
I've made a new set of REST APIs for a legacy monolith application and faced the same questions.
I will answer this question first:
How services and controllers should be separated in directories?
I went down the src/Service/{Something}/{Something}Manager.php path as I thought that that was the way. As the project has grown, I regret that and will be moving to src/{Something}/Service/{Something}Manager.php
Why?
I find the separation in namespacing much easier to read and much
harder to accidentally use the wrong class.
I now have files split out across the application and it's much harder to abstract it into a library that can be re-used by other applications.
I can't refactor functionality as easily - everything is spread out an
intertwined. If I were converting a monolith, I would prefer to have
code to refactor that was bound by some function so I could work on
that, before moving to the next.
There are other reasons but feel the need to separate this back out before the application gets any larger.
How services.yaml should look like? Well, the autowiring is amazing. I would keep your service yamls in the various functional splits (as above) and start refactoring them out. With the default autowiring config, you'll find that very little needs explicit definitions.
Where would you put UserAuthenticationProvider and/or WebSocketServer?
For the provider, probably something like, src/Security/Authentication/Provider/UserAuthenticationProvider.php.
For the WS server, I'm not really sure - it depends where it sits in the app and how it's used.
To start with, S4 still supports bundles pretty much as before. The config section has been reorganized a bit but if you already have a huge app working under bundles then you might just consider keeping it more or less as is. It should still work just fine with minimal tweaking.
There are a couple of approaches for a bundle-less app. Typically you would group files by functions using feature sub-directories to keep things organized.
Assume you have three existing bundles called FooBundle, BarBundle, JarBundle
config
services
foo.yaml
bar.yaml
jar.yaml
routes:
foo.yaml
bar.yaml
jar.yaml
src
Controller
Foo
Foo1Controller
Foo2Controller
Bar
etc
Entity
Foo
foo entities
Bar
bar entities
Form
etc
templates
foo
bar
jar
You get the idea. Might be worth modeling this all out in advance especially to see where the odds and ends might fit. And probably use the App namespace for everything. This approach pretty much follows the Symfony 4 best practices. Can't really go to far wrong with it.
There is at least one other approach in which you group files by features. I won't go into much detail as it's definitely not the normal Symfony approach and will take some tweaking. But you could do:
src
Blog
routes.yaml
services.yaml
BlogEntity.php
BlogVoter.php
Edit
BlogEditController.php
BlogEditForm.php
BlogEditTemplate.html.twig
etc
Show
BlogShowController.php
etc
Related
What I'm looking for is a way to remove the model from a set of PHP files that make up a website. It's difficult (for me) to explain.
By models I mean models in an MVC sense.
As an example say I have this website:
index.php
about.php
shop.php
checkout.php
All of the above PHP files use the same database. I have separated the views by adding templates using a view.php file that renders the correct template with values passed to it.
I am not looking to use a framework that's already out there. I'm looking at writing my own in some senses, with only the bits I need to use in it.
If anyone would like to explain why this is not necessary, or a better way of doing things, then I'm open to that too.
Thanks in advance.
Writing you own MVC framework will take time, but you will learn a lot in the process. So, if you have the time/resources to do it I definitely encourage you to do so.
In this context here are some small pieces of advise that may help you:
Create your domain model first. I'm assuming that you are going in the OO way, so think about your domain problem and create the abstractions that best represent your problem. Try to keep it decoupled from cross-cutting concerns, like persistence.
Test a lot, test often. Try to test (and run your tests) as you create your domain model. This will be specially valuable when in 6 months you add a new feature and want to make sure that you haven't break anything. If you can separate your domain model from anything external (like the persistence layer or third party web services) the testing it is going to be a lot simpler. Today PHPUnit is pretty much the de-facto standard for unit testing in PHP.
You don't have to write everything from scratch. There are a lot of libraries that can help you to ease the development of an MVC framework, so that you can concentrate on what you really want to develop. For example, you could use Slim to handle the page routing or you could delegate the persistence stuff to Doctrine 2.
It is always nice to analyze how other frameworks solve things. You may want to look at products like Symfony or Kohana or even check how Elgg handles its views system. Also, if you want to check out something radically different you can take a look at Seaside's architecture.
Coming back to your original question, for me the key is to keep things from different layers as decoupled as possible. While I have only used the version 1, Doctrine 2 seems like a good candidate for persistence, since it allows you to create a domain model that is quite independent from the DB. This is a huge step. The second thing is how handle the view system. This is quite developer-taste dependent. For example, I like to model everything with objects, so I like Seaside's approach. On the other hand, Elgg's way of handling views is quite nice and maybe fits better with the way things are handled in PHP. Here is when you may benefit on doing some research before deciding on a route to go.
HTH
As someone who has written his own PHP framework, and with the same sensibility as yours, I can tell you that using a framework is a fine thing to do. That said, start by writing your own - you'll gain greater appreciation for the true structure and utility of a framework.
You'll want to learn about the Singleton object pattern. It is a major differentiator in the kinds of objects you can develop in your framework.
When you have written a few models that your files/controllers (presuming MVC) include, you will begin to see where to abstract a 'base mode' from which others extend (hint: the DB singleton).
When you start pulling in configs and the like, then you'll have your first framework object from which all other bases do their extension.
I have almost completed a PHP project, using MVC, jQuery and Ajax. It is pure PHP project. I don't use any frameworks in the code right know. I would like to change that.
Doing some research, I found, that Yii turns out to be one of the best frameworks out there.
Is it possible to somehow migrate pure PHP project to Yii?
If so, then how to do this? Which steps should I follow in order to reduce the workload and enjoy the benefits the Yii framework presents?
I'm a total Yii newbie, any insights appreciated.
TL;DR : Don't do it. It's a really horrible idea.
The Rant ..
"Framework" is not a magic sauce, that you add to a project, to make it better and shinier.
Doing some research i found Yii turns out to be one of the best frameworks out there.
What a strange research you have done .. I would love to see the materials. Especially, since I would rank it as 3rd worst PHP framework. Only surpassed in it's awfulness by CodeIgniter and CakePHP.
And the reason for it is the extremely bad quality of code, that this framework displays, combined with the bad practices, that it perpetuates.
Why avoid migration?
From your description is obvious, that you are NOT familiar with this framework and have no previous experience with it.
In management of projects there a subject: risk management. And in this case, adding a previously unused framework in final stages of project would constitute a high probability an high impact risk which also, due to the sage of project, is completely unmitigated.
It means that there is a really good chance that something will go wrong. And when it does, it most likely will sink the project. Or at least push back the release data by significant length of time.
In a perfect world frameworks are used to simplify the repetitive tasks of development, at the cost of some performance. Those are the tasks you do at the start of the project. You are not at the start of a project. This means that you will gain no benefits from this "maneuver".
Why not Yii?
As I noted before, there are also reasons not only for avoiding adding framework to an existing project, but also reasons why to avoid Yii in particular.
The inheritance nightmare
All your controller will extend class CController, which extends CBaseController, which extends CComponent
All your "models" will extend ether CActiveRecord or CFormModel, which extends CModel, which extends CComponent.
Both of there chains contain static variables and execute static methods on multitude of different other classes. Combination of these factors will make debugging extremely difficult and tedious.
Global state
There are several forms of global state. One that people in PHP usually know are global variables. But that is not the only form. Every time you have a class that contains a static variable, it also creates a global state, that can (and almost always - will) cause seemingly unrelated instance mysteriously interact.
Use of global state is a core mechanic. You will see static calls all over the codebase, and the Yii's configuration file would not function without global state.
And every time you call Yii::app() you are accessing and/or changing it.
This makes unittesting impossible for Yii applications. And debugging turns into exercise of using grep on your whole project.
Tight coupling
When you create an application in Yii. It becomes bound to it. You cannot execute parts of your application without launching the full framework. Mostly it is due to the static call, that you end up adding to your code.
Every time you add a static call in your own code, that piece of code becomes tied to the name of the class. That essentially is tight coupling.
As you might have noticed (hopefully), there is another way how to achieve the same effect - the use of new operator. That is another way of coupling some code of yours to a specific name of a class.
No interfaces .. none .. whatsoever
No matter how horrible the configuration of a Yii project is, the configuration file was a well intended gesture. The least harmful way to introduce external code and replace existing components in so messed up codebase.
But unfortunately it brings in the focus the problems caused by lack of interfaces and the existing coupling.
One of the component that developers will try to replace is the CUrlManager. Mostly due to way how you can pass additional parameters.
An interface in OOP specifies the contract between two instances. It lets you define the capabilities of an instance, the methods that can be used by others. When it's not there, in a large codebase, you are left guessing, which methods are required and which are not.
In case of Yii components the problem is compounded even further due to static call and deep inheritance. The above mentioned CUrlManager extends CApplicationComponent, which extends CComponent. Also the same file defines CUrlRule and CBaseUrlRule classes.
When you are writing a replacement, you have to write some code, plug it in the configuration and then test it by running your applications. That way you know which method (or parameter) next you need to add.
Basically, it's the "save-an-see-what-blows-up" method of development.
That's not MVC!
Yii does not implement MVC or any of MVC-inspired design patterns. What it calls "MVC" could be described as ActiveRecord-Template-Logic pattern.
Instead of having proper model layer (yes, it should be a layer), the creator(s) of Yii opted for collection of active record and form wrappers. This forces the application logic to be forced in the "controllers".
On the other hand you have glorified templates, instead of proper view instances for containing presentation logic. It is somewhat mitigated by use of widgets, but those instead suffer from SRP violations, because widgets are forced to contain bits of presentation logic and perform partial rendering. The rest of presentation logic ends up again in the controllers.
And to make it all worse, the "controllers" also have to deal with authorization. This usually will mean, that whenever you change the access scheme, you will have to go through every single instance of CController to check whether it needs to be changed too.
It's not MVC. It's a mess with names taken from MVC design pattern and slapped on some components.
All the small things ..
The framework also comes with few minor issue, that do not deserve a separate section:
Defining more then one class per file:
This will get annoying quite fast, because there will be classes that are shoehorned at the class files with completely unrelated filenames. This will mean, that debugging will quite often require use of search.
Slapped on "modules":
By the looks of it, the modules where added to the framework after the fact. Which is why, when you need to set default module, you will have to set it in the configuration files parameter, that is called 'defaultController'.
I actually recently converted a MVC pattern website I had built from the ground up into Yii. It did take some time to set it all up but in all honesty it was well worth it. I was able to throw away a lot of code because there were already Yii extensions doing what I needed. I would also suggest that you keep your database because you can create the controllers and Models using Gii which will save you a ton of time.
I don't know of any quick solutions to this. It depends upon how the code was written. You have the database and your views so it is not really a complete new project when you take into yii. Yii will generate the database models for you. You already have the views from the existing project. Write the controller and actions and modify the views if necessary.
try these links as they refer to the same problem.
How do you convert an old oop project into Yii
tips on migrating an existing site to Yii
Drupal to Yii Migration
Since you already have a code in mvc, things will be much easier for you to migrate. However, while migrating to Yii, since it can generate controller and model very easily using gii, you can take the advantage of it.
So, first generate controller and model using gii, then you can replace your existing code (by replace I mean, substitute your code to the specific function in the controller and model) to the built in controller and model so that the functionality of your site still works. You can modify your view accordingly. But that won't be much of a work.
You can simply register your script for ajax, jquery and css. Those will work as well.
And yes, Yii is the best framework out there so take as much benefit as you can.
Thanks,
Ujjwal
In this project you converted php to yii framework. Its really easy for you if you do following step.
Since you already have a code in mvc, things will be much easier for you to migrate. However, while migrating to Yii, since it can generate controller and model very easily using gii, you can take the advantage of it.
second, If your database is accurate then 50% work complete.when you create CRUD operation using gii then automatically model-view-controller create.if you create mvc in php then it benifit for you.
third,You can simply include your script for ajax, jquery and css. Those will work as well you create a folder in themes(CSS,JS,AZAX,BOOTSTRAP).
four-Protected->view->layout, where you can change your theme..thats all
you also help www.yiiframework.com/doc-2.0/guide-intro-yii.html
if you think my answer is help you then rating me...thank you.
This might be an obvious thing to you but - even after reading through a lot of manuals and blogs - I'm still not sure what exactly should a bundle in Symfony2 represent in a webpage. And it's hard to guess it from the simple demo applications.
For example: I have a site which is divided into two parts (one is just a 2nd level domain like example.com and another is dom2.example.com). Each of these two parts has some sections of it's own - sometimes the same (like news) sometimes different.
What would the correct representation of this in symfony2? Should I have
a MySite\site1 and MySite\site2 bundle and do the different sections via different controllers, or
bundles Site1\News and Site2\News, or
bundles MySite\Site1News and MySite\Site2News etc.
...or am I getting all wrong at this?
I am also new to Symfony and will follow the results of this question with interest, but for what it's worth, my take on it is:
A bundle is just that: a group of files, assets, PHP classes and methods, tests, etc. The logic of the grouping can be anything you like. In some cases, it's really obvious what the grouping is and why it's been done -- for instance, if I wrote a blog system for Symfony2 and wanted to release it, I'd make it into a bundle. That's the sort of example used most in the documentation.
But you'd also use bundles for anything you wanted to release as one little feature. Say for instance, this bundle which creates default routes for all your controllers. It's not a fully developed plugin/feature like a blog or forum, but it's a bit of code that I can easily import into my project, it stays totally separate from everything else, it's a bundle.
Finally, you'd also use bundles internally to your project, in absolutely any way which makes sense to you.
My take on your specific situation:
Quick and easy:
MySite\MyCode -- gets the job done, and maybe you don't have any logical way to break up the code you're going to write.
If there's some more unique features between the two sites and you want to separate them out for clarity:
MySite\SharedFeatures
MySite\Site1Features
MySite\Site2Features
If you really like everything in its place, or if you have a complex project, maybe:
MySite\MySiteMain (shared features and catch-all miscellany that doesn't deserve its own bundle)
MySite\News
MySite\Site1FeatureSomethingOrOther
MySite\Site2FeatureSomethingOrOther
I definitely think you want to stick to logical groups of code -- so I think your example "bundles Site1\News and Site2\News" and "MySite\Site1News and MySite\Site2News" wouldn't be the best way to go. Site1 and Site2 are implementations, so making a separate bundle for each site's news page would seem to be counterproductive to me; you'd want to make one news component and build it to be used in two different ways.
As for your two-domains question, you can either point both domains at the same code, and test within your code for what domain is being requested, or you can check out two copies of the same code and change the configuration files slightly (this doesn't necessarily violate the idea of DRY because you'd still edit the code in one place, then update both copies.)
The way I understand a bundle is that it is similar to what CMS like e.g. Typo3 or Drupal call a "plugin". So it should be ideally self-contained and written in a way that it can be used on other projects too.
E.g. in your case I'd create a "staticHtmlBundle" that contains all the static pages of your website, divided within by site.com and dom2.site.com.
Then I would create a "newsBundle" that contains all the news-articles, maybe even database-driven with a little admin-section where you can edit them and assign them to different channels (in your case that is site.com, dom2.site.com). A static page from within staticHtmlBundle would call newsBundle and display its data (like e.g. a listView of the news or a detailView and so on).
If you keep everything as abstract and reusable as possible then you could even publish the newsBunde in the Symfony 2 Bundle repository and share it with the community!
The way I perceive Symfony2 bundles is that they are provide a modular system which allows you to not only extend and override the php code, but also any resources they may or may not include.
Having said that, consider you have an API and you would like to transfer an object.
How would you do that?
Of course, you can do that manually, but wouldn't it be nice if Symfony can do it for you?
My way of doing this would include 3 bundles, JMSSerializerBundle and FosRestBundle.
One bundle for the client side - MyCompany/ClientBundle
One bundle for the server side - MyCompany/ServerBundle
One bundle housing all the data transfer objects I would like to be able to transfer - MyCompany/CommonBundle.
Inside my MyCompany/CommonBundle I would have the classes I would use for my data transfer objects along with the serialization rules I would have to provide the JMSSerializerBundle with. They may be in the form of xml, yml or php annotations.
Once you have an object filled up with the data, you can just use return and FosRestBundle would serialize it for you. Serialization would depend on the routing, so you can have the object serialized in XML for one system and in JSON for another. Key point is you have different serialization formats and versioning you can utilise at later point.
On the client side, you can use simple param converter to convert the received JSON or XML to an object right in the controller with no additional hassle. You can also type in some validation rules, so you can verify if the object is populated as you expect it to be.
In my example, the MyCompany/CommonBundle has objects that would be used by multiple applications and would be identical. Having that as a separate bundle helps you avoid code duplication and makes long term maintenance a lot easier.
I hope I managed to explain this. Any questions?
Ask in the comments. Will update the answer accordingly.
I am quite a new Zend Framework user but I am not new to PHP or Programming. I have been going through the code to try and get to grips with how everything slots together. One of the parts I have been looking at is how classes are Autoloaded in the system. I can see that:
Zend_Application_Bootstrap references Zend/Application/Bootstrap.php
Zend_Controller_Action references Zend/Controller/Action.php
... etc etc
Essentially _ get converted to the directory sepearator and get autoloaded.
What I don't understand (although im sure there is a good reason) is why this convention isn't followed for action controllers?
IndexController references Application/controllers/IndexController.php
Why not:
Application_Controllers_Index -> /Application/Controllers/Index.php
or
Controllers_Index -> /Application/Controllers/Index.php
?
I am guessing giving the class a suffix reduces some complexity in the system somewhere, from first looks at the zend framework everything is very well thought out - I cannot imagine conventions are introduced without good reason.
Can anyone explain why controllers are prefixed, or even better point me to some code in the core showing why they have to be prefixed?
Thanks :)
To be honest, I'm not entirely certain as to why the conventions were originally developed. I suspect they had to do with how other frameworks were evolving at the time -- in particular, RoR was spiking in popularity, and this was how they defined application resources. (At the time of the original MVC iteration, I was just starting at Zend; I did a rewrite in fall of 2006, but the goal of that was to keep it as consistent with what had been developed previously, while simultaneously offering better and more flexibility.)
We've continued along the paragigm as it reinforces the idea that all items under the application/ hierarchy are resources, and not your library code. This is particularly important due to the fact that you may have non-class code within this tree (view scripts, layouts, etc.).
However, this has certainly made for a few headaches -- the introduction of the resource loader shows that we had a problem we needed to resolve. The resource loader basically addresses the symptoms, but not necessarily the root cause (poor conventions). As we work on ZF2, this is something we will be revisiting. If you're interested in posting your thoughts, I invite you to do so on the zf-contributors mailing list.
File names and classes names of Controllers should has a postfix Controller. Zend see a postfix in class name, and understand, that it is a controller. He finds this class in controllers folder.
I'm only fairly new to Zend Framework myself, but from what I can tell, given the way the Zend Framework currently stands there is no good reason for this. I'm not sure if it's a hangover from the way things started out, or just the preference of people involved, but I've heard this will be changed for ZF 2.0.
I've got a somewhat primitive framework I've been using for most of my projects, but a general design issue came to mind that I haven't been able to work out yet. For a given application, should I separate the application-specific class structure from the framework's structure, or is building on top of the framework not such a bad thing?
For example, say I had a framework with a base Controller class and extended it for a given part of my application. Which arrangement makes the most sense, and why?
Class Structure A:
Intuitive, easy to find source files when debugging.
File naming/directory structure mirrors class heirarchy.
- Framework_Control "Framework\Control.php"
- Framework_Control_Index "Framework\Control\Index.php"
- Framework_Control_Home "Framework\Control\Home.php"
- Framework_Control_Contact "Framework\Control\Contact.php"
- Framework_Control_About "Framework\Control\About.php"
Class Structure B:
Keeps framework modular and easily to replace/update.
Adds some complexity to directory structure, directory/file naming no longer follows class heirarchy all the time.
- Framework_Control "Framework\Control.php"
- Application_Control_Index "Application\Control\Index.php"
- Application_Control_Home "Application\Control\Home.php"
- Application_Control_Contact "Application\Control\Contact.php"
- Application_Control_About "Application\Control\About.php"
I know overall it's going to come down to personal preference, but I want to make sure I weigh out all the pros and cons before I decide which way to go. It really comes down to class naming and directory structure as the actual hierarchy would remain the same in either case.
I would suggest that you view your source code in two different categories, external dependencies or code that is used across multiple sites and not native to any single one and native dependencies or the code that is native to the particular site that you're working on.
It sounds like Framework/Control.php is part of a larger external dependency and should be managed as such, while the Application/Control files are all native the particular website.
Using this differentiation in our code structure has made it much easier to reuse our in-house framework between multiple sites very easily.
As a final thought, you might consider looking at what the major frameworks out there are doing such as Zend Framework, Symfony and others. Even though the entire framework might be more than you want the structure of the frameworks can provide a lot of insights into common, good practices that are being used by PHP developers everywhere.
What it really comes down to is what are you going to do when you update Framework\Control.php in Application XYZ. Are you going to go back to Application ABC and make that same change? What if it's a critical bug?
For maintainability of all of your projects I'd go with your second option.