Related
The symfony 2 installer gives a best practice directory structure, but not a lot is said about how these directories should be used, where does each piece of code belong, sure the symfony framework narrows it down to views, entities and controllers, services etc. but more often then not, programmers end up putting a DQL query inside a controller and some logic to handle a specific task, while this does the job, there has to be a better method, even beyond symfony's out of the box directory structure, currently on a quest for better design pattern that would modularize and reuse as much as possible
On this quest, found a couple good articles on the interwebz, and spent a day on it, came up with a plan to separate all DB interactions to repositories, all logic to services, and keeping the controller 'thin' which acts as a central point for calling methods from repository and calling services. sounds good, will be modular and code can be reused.... BUT
This somehow moves away from OOP concepts and right into procedural programming, not that there is anything wrong with it, its just not leveraging the powerful concepts of OOP
Could making the objects more 'powerful' by adding in more functionality make it better? the services by definition should do a unit of task, will my approach make them big and ugly
a few good points on this blog here but could't really make out what they were trying to suggest as a solution
In general, the more behavior you find in the services, the more
likely you are to be robbing yourself of the benefits of a domain
model. If all your logic is in services, you've robbed yourself blind
-Martin Fowler
to summarize is Service oriented approach not leveraging the concepts of OOP? and how could this be supplemented
One of most important thoughts which you can find in Fowler's "Patterns of Enterprise Application Architecture", is that you should use right tools for your job. Depending on the complexity of your problem and domain, one or the other design pattern/architectural pattern may perform better. And following that way, in contrast to old frameworks (ZF1, SF1), SF2+ doesn't force you to go for any architectural pattern or organizing your business logic in specific way. You can even put everything outside bundles structure. So the best thing, which you can do, is to try learn more about design patterns (generally). And then, when you need, you will be able to pick one which will work best for your case.
You may want to look at:
mentioned earlier "Patterns of Enterprise Application Architecture", especially chapter: "Domain Logic Patterns".
The Four Architectures that will inspire your programming short review of different architectures.
any of books covering DDD, like: E.Evans "Domain-Driven Design", V.Vernon "Implementing Domain-Driven Design" or S.Millett and N.Tune "Patterns, Principles and Practices of Domain-Driven Design"
Domain-Driven Design in PHP decent book covering implementation of DDD patterns in PHP application, with some examples based on SF.
The Clean Architecture in PHP implementation of The Clean Architecture for PHP, focusing a lot on framework independence (with examples for ZF2 and Laravel).
With Domain Driven Design it creates fat model layers, and also calling a lot of services inside your controller may modularize your code, it still has its own set of challenges, it makes the design harder to create, and at some point there will be too many service calls inside the controller, what can actually be done is to use a few concepts from DDD.
two things to remember before starting DDD is :-
cohesion - modules that change together
coupling - modules that are dependent on each other
You need to lessen the coupling and recognize the cohesion and design the project according to it, main goal is to allow adding and removing or enable/disable/recombining of modules in future, in case you decide to alter the project
instead of having bundles depend on each other use interfaces instead
namespace MyProject\UserBundle\Activity ;
use MyProject\NotificationBundle\Notification;
use MyProject\MailBundle\Mail;
where UserBundle is coupled with NotificationBundle and MailBundle use interfaces that abstract the bundles instead
namespace MyProject\UserBundle\Activity ;
use MyProject\ServiceBundle\NotificationInterface;
use MyProject\ServiceBundle\MailInterface;
Main concepts of DDD are
value objects - an object that holds some data and is passed back and forth and does not focus identity but rather on the data that it holds, value objects can be used in symfony using embeddables
Entity - an object that holds some data but is dependent on an identity value rather than its data value
Repository - use of repository classes to make database operations make it possible to change the implementation later on, as it is centralized to one place
Aggregate - when several object belong together like a number of things that belong to a single category (eg: songs that belong to a genre), the entire collection of objects are treated as one and to make alteration to these objects would be thought on single aggregate object
Domain Events - any change in the state of the domain/data is regarded as an event, in symfony there are Event Listeners and Subscribers which can stand in for domain events, this is one of the most important concepts of DDD, filter also a great deal of improvement to the code
services - services are callable modules of code that do a unit of work, services allow code to be reused and are easier for testing and updating, services in symfony should contain the domain logic and the service layer can get pretty fat, this along with events make the code faster and more maintainable
Factory patter - this patter uses a 'factory' object that generates a different object, by doing this the name of the second object is abstracted, this helps when refactoring the code
these are generalized concepts that need to be applied to code that is highly situational, proper DDD requires the code to be modular which is a challenging task to achieve and need some experience on the engineer's part.
as already stated by others, books by 'martin fowler', ' V.Vernon' design patterns by ' gang of four' etc would be a good read
First of all there are best practices where to place files/components: http://symfony.com/doc/current/cookbook/bundles/best_practices.html.
Secondly http://symfony.com/doc/current/best_practices/business-logic.html:
In Symfony applications, business logic is all the custom code you write for your app that's not specific to the framework (e.g. routing and controllers). Domain classes, Doctrine entities and regular PHP classes that are used as services are good examples of business logic.
So you are not forced to use any architecture for your business logic.
Regarding your question - you can implement objects with operations and declare them as services (or use them directly, but in this case when you want to replace some functionality you'll need to rework more code).
there are always a lot of principles of software designing and we select what we think is more correct and makes more sense for a project and Symfony doesn't force us to use some special design pattern.
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.
I've been learning Zend and its MVC application structure for my new job, and found that working with it just bothered me for reasons I couldn't quite put my finger on. Then during the course of my studies I came across articles such as MVC: No Silver Bullet and this podcast on the topic of MVC and web applications. The guy in the podcast made a very good case against MVC as a web application architecture and nailed a lot of what was bugging me on the head.
However, the question remains, if MVC isn't really a good fit for web applications, what is?
It all depends on your coding style. Here's the secret: It is impossible to write classical MVC in PHP.
Any framework which claims you can is lying to you. The reality is that frameworks themselves cannot even implement MVC -- your code can. But that's not as good a marketing pitch, I guess.
To implement a classical MVC it would require for you to have persistent Models to begin with. Additionally, Model should inform View about the changes (observer pattern), which too is impossible in your vanilla PHP page (you can do something close to classical MVC, if you use sockets, but that's impractical for real website).
In web development you actually have 4 other MVC-inspired solutions:
Model2 MVC: View is requesting data from the Model and then deciding how to render it and which templates to use. Controller is responsible for changing the state of both View and Model.
MVVM: Controller is swapped out for a ViewModel, which is responsible for the translation between View's expectations and Models's logic. View requests data from controller, which translates the request so that Model can understand it.
Most often you would use this when you have no control over either views or the model layer.
MVP (what php frameworks call "MVC"): Presenter requests information from Model, collects it, modifies it, and passes it to the passive View.
To explore this pattern, I would recommend for you begin with this publication. It will explain it in detail.
HMVC (or PAC): differs from Model2 with ability of a controller to execute sub-controllers. Each with own triad of M, V and C. You gain modularity and maintainability, but pay with some hit in performance.
Anyway. The bottom line is: you haven't really used MVC.
But if you are sick of all the MVC-like structures, you can look into:
event driven architectures
n-Tier architecture
And then there is always the DCI paradigm, but it has some issues when applied to PHP (you cannot cast to a class in PHP .. not without ugly hacks).
From my experience, the benefits you get from an MVC architecture far outweighs its costs and apparent overhead when developing for the web.
For someone starting out with a complex MVC framework, it can be a little daunting to make the extra effort of separating the three layers, and getting a good feel as to what belongs where (some things are obvious, others can be quite border-line and tend to be good topics of discussion). I think this cost pays for itself in the long run, especially if you're expecting your application to grow or to be maintained over a reasonable period of time.
I've had situations where the cost of creating a new API to allow other clients to connect to an existing web application was extremely low, due to good separation of the layers: the business logic wasn't at all connected to the presentation, so it was cake.
In the current MVC framework eco-system I believe your mileage may vary greatly, since the principles are common, but there are alot of differences between, for instance, Zend, Django, RoR and SpringMVC.
If there are truly other good alternatives to this paradigm out there... I'm quite interested in the answers!
Sorry for the slight wall of text!
I think it would depend on what you're trying to do, personally. Magenta uses MVC pretty successfully, and it makes it fairly easy to add new functionality or modify existing.
Of course if you're trying to make something fairly simple, going with an MVC architecture could be overkill.
It's all preference. I have worked with old structures like XTemplates and Smarty and have now moved on to Codeigniter and Kohona. I like them very much and they work very well for everything I do on the web. For phone applications I can set up controllers for the functions that are needed to do it's data pulls as well. Working both in the Linux world and Windows World, for building ASP.NET Web Sites I don't see other way of building websites beside using MVC. Web Applications Projects in Visual Studio are still used but I prefer not to anymore. MVC Projects via Visual Studio is so easy to use and set up. You can right click on your controller methods and create views automatically. In every structure there is a good and bad but it's up to the developer to use whatever meets their needs.
I don't want to reinvent the wheel, so ask how others do this ...
I have 2 upcoming projects, one in Delphi and one in PHP (plus maybe one in Java), so info specific to those would be welcome, but a generic answer is also acceptable.
So, I have a bunch of PCs and a database server (ODBC) and want to develop an MVC app.
I guess that the Model is on the d/b server and that the view is on each individual PC. Where is the controller? One on the d/b server, or one copy on each PC?
When writing data I imagine it is enough to lock the relevant d/b table(?). But how to update all of those views and tell them that there is new data or that the data which they are working on has been modified on deleted by another user?
Any code is welcome as are URLs or book recommendations ... thanks
Suggest you start with this
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Its a regular intranet app right? why do you want to split everything separately. Models, views and controllers are just the respective files where you do the relevant stuff, they dont reside physically on a separate locations. I think you have got the Concept of mvc completely wrong. MVC means splitting and layering the code based on their functions not keeping them physically separate.
To be more clear in a laymans language your models views and controllers are just directories in your application. Your view files goes in to your view directory(not necessarily this is changeable though) your models that is your DB related operation files goes into models and the classes that control and drive your app goes into your controller directory.
Running it on intranet is quiet simple. ALl you have to do is host your files on a system that has a static IP or Name within your network then from other systems go to your browser and point your browser at
http://myserver/myapp or http://192.168.100.100/myapp
I dont know anything about delphi, but what ever i said above stands for PHP and many other languages.
So taking all the above points in you are not going to update the views separately on each system all files are in your central server and any changes made in them automatically reflects when requested from the clients.
From your question i assume you are completely new to web development or atleast mvc so first have a look at some simple mvc like codeigniter in PHP. CI has a very good DOC so you can come up to speed.
Hope i have answered all questions.
As far as I understood MVC, there is no rule about the location of the controller itself.
Please take in consideration that MVC is an architectural pattern, not an hardware nor even logical design. If, like in any n-Tier architecture, it could make sense to have the DB in a dedicated computer (for performance and maintainability/backup reasons), controllers and views can be... everywhere...
MVC is a pattern, that is, more a way of modeling/interfacing objects and classes than a way of distributing your application into modules. In fact, you can (and IMHO should) share MVC code among client and servers, whereas the objects are still implementing Model/View/Controllers in a separated way.
A "classic" MVC implementation (e.g. used by RoR or by DoR or Relax in the Delphi world - both in draft status) uses directories or files to split views and controllers. But this is just one implementation design of this pattern.
You can have a pure object MVC orientation, as we implemented for instance in our ORM framework. You can in fact have objects everywhere, to handle your model, to access the DB, to handle your business services.
In our mORMot Open Source framework, for Delphi 6-XE, you can follow this development pattern:
Data Tier is either SQLite3 and/or an internal very fast in-memory database, and/or any other external database (via OleDB or OCI), most SQL queries are created on the fly by the ORM kernel;
Logic Tier is performed by pure ORM aspect: you write Delphi classes which are mapped by the Data Tier into the database, and you can write your business logic in both Client or Server side, just by adding some events or methods to the classes; a Service-Oriented-Architecture (DataSnap-like) is also available, and can be used without any object;
Presentation Tier is either a Delphi Client, either an AJAX application, or any other back-end able to communicate using RESTful JSON over HTTP/1.1 - in this case, PHP or JAVA clients are perfect candidates.
I suggest you take the time to download and take a look at the mORMot documentation. It's far from perfect, but it tries to be complete. In the SAD document, you'll find some pages about the architecture we implemented, in particular MVC, n-Tier, SOA and ORM. Don't be afraid of the 1000 pages of PDF - you don't have to read it all: I just added some general diagrams which may help you modeling your solution.
In all cases, taking a breath before implementing a solution for your project is a very good decision. The time you'll spend now by looking at existing architectures will certainly save you pain in the future. Good start!
I have asked a similar question before and got an convincing answer as well?
What is difference of developing a website in MVC and 3-Tier or N-tier architecture?
Due to the conclusion of this question I started developing projects in N-tier Architecture.
Just about an hour ago, I asked another question, about what is the best design pattern to create interface? There the most voted answer is suggesting me to use MVC architecture.
What is the best design pattern to design the interface of an WebPage?
Now I am confused, First post suggested me that both are similar, just a difference that in N-tier, the tier are physically and logically separated and one layer has access to the one above and below it but not all the layers.
I think ASP.net used 3 Tier architecture while developing applications or Web applications. Where as frameworks like Zend, Symphony they use MVC.
I just want to stick to a pattern that is best suitable for WebProject Development? May be this is a very silly confusion? But if someone could clear this confusion, that would be very greatful?
They aren't mutually exclusive. The Model-View-Controller pattern is really a user interface design pattern, and it concerns logical rather than physical tiers.
I most often hear "n-tier architecture" used to describe the actual physical separation of an application's layers. For example, a system in which the user interface runs in one process, exchanges data with an application layer (perhaps via messaging or web services) that executes in another process (perhaps on another server), which in turn accesses a data layer that runs in yet another process (typically a database server).
This description can be particularly confusing because 'application logic' can mean multiple things: in an n-tier system it usually means business logic - as opposed to user interface logic (like which widgets are enabled when the user selects a particular checkbox).
For example, in an n-tier system, your presentation layer might call a web service method that accepts an item ID. The web service runs on a different server, where it performs complicated calculations and returns a price.
In a simpler architecture, your application might calculate the item's price in the same process as the user interface - though the pricing logic may be separated into its own logical layer (perhaps within library or executable).
I can't think of any current MVC frameworks that care whether their layers run in separate physical processes or not.
I just want to stick to a pattern that
is best suitable for WebProject
Development? May be this is a very
silly confusion? But if someone could
clear this confusion, that would be
very greatful?
I think your confusion lies in two areas:
1) The assumption that there's one solution for every problem.
The requirement of your project will dictate which solution is best.
2) The definition of MVC when applied to the web is different than when it originally applied to desktop applications.
Some folks say that if the view doesn't talk to the model, then it can't be MVC. Well, most of the web MVC implementations don't have the view talk to the model, yet it's still called MVC.
Since you are a self-described amateur, you should embrace this one axiom early on: the programming world is confusing to everyone all the time.
You may want to review the Microsoft Application Architecture Guide. It has a good overview of the available Microsoft technologies from an Architecture standpoint. Chapters that might be of interest to you:
Chp 21 Designing Web Applications
Appendix B: Presentation Technology Matrix
Appendix C: Data Access Technology Matrix
As for what is best? You have to answer that yourself. Make some sample projects using MVC, WebForms, etc.
Web-based MVC is much different than the traditional desktop MVC. The Model simply has no way to update the View, because the web is (for the most part) stateless.
Even if you used AJAX to poll the server every couple seconds to check for Model updates, that still wouldn't be "true" MVC because it's not the Model notifying the View, it's the controller constantly "querying" the Models.
The lesson learned is that it really doesn't matter what you label your architecture. There are just so many variants of MVC/3 tier that usually people just lump them under the "MVC" blanket. And all of these are suitable for web development. I just can't think of any practical way to have the Model actually notify the View through server-side programming (at least not in PHP). If you need this kind of behavior, you should be writing a desktop application. Just write what is natural for you and don't get caught up in terminology debates. Look at what some of the well known frameworks like CodeIgniter, Kohana, Symfony, CakePHP, and Zend do and pick and choose which features or design patterns you like.
Why not use both?
At the moment I'm busy developing a project using the MVP pattern and in an N-tier architecture.
I'm using the MVP pattern in the user interface project, ie. the website. All the data which needs to be shown and used in the website is passed from a webservice. This webservice is connected to a business layer (BLL), which is connected to the data access layer (DAL). The DAL is connected to the database using the Entity Framework.
So in this project I'm using them both. Using MVP instead of MVC though.
This way the interface project (website) doesn't has to do hard stuff, only pass through some data which is received from the webservice. Took me a while to set up, but it works quite wonderfull.
Also, there is no real answer to which pattern or architecture is the best. It all depends on what you want and need. If you want to be scalable, an n-tier architecture is a good solution. If you want to be able to test your UI quite easily, an MVC pattern is good also. There's a ton of other patterns and architectures which would suffice as well, as long as you know how to use them.
There is no which is better. MVC and n-tier are not either or things. One is object/API design, one is system architecture. The question to distinguish between the two has been asked and answered here:
MVC Vs n-tier architecture