I have to create a php project using Codeigniter and Doctrine.
I worked alot with j2ee and I would like to use the same project structure in my php project.
So here is what i'm thinking:
Controllers eg(UserController)
Services aka Models Interfaces (UserService)
Services Implementantions eg (UserServiceImpl implements UserService)
Dao Interfaces (UserDao)
Dao Interfaces implmentations eg(DoctrineUserDao)
Doctrine Entities
Views
I haven t seen implemented in php projects interfaces for services and dao design pattern is always missing. Are Interfaces and DAO redundant in php mvc projects ?
And another question: as far as I know Codeigniter loads model using the following syntax:
$this->load->model('UserServiceImpl'); which is kind of lame in my opinion, i prefer using autoloader with namespaces, is this bad ?
I've designed a few smaller systems with CodeIgniter, and now I'm designing/building a big one. I always followed the same structure (the one I'm going to describe here) and it worked for me very well so far. For my current project we tried to use Doctrine as the ORM, but in the end I decided to leave it out from the project - it was more of a burden than help.
(I may use slightly different terms for the layers, but I tried to put them in parallel with your terms wherever I could.)
The structure I use is:
Controllers (e.g. /application/controllers/UserController.php)
Data Mapper (ORM) layer (e.g. /models/tables/UserTable.php)
Domain Object layer (e.g. /models/data_models/User.php)
Layouts (e.g. /models/layouts/default.php)
Templates (views) (e.g. /application/templates/user/view-profile.php)
Responsibilities:
(2) Data Mapper layer contains all the SQLs, and all Doctrine EntityManager usages. It stores and retrieves Domain Objects.
(3) Domain Objects represent the entities (with entity metadata described in comments for Doctrine, using the Docblock Annotations format).
(1) Controllers do only the logic of calling the ORM layer, maybe do some restructuring of data or calculations.
(4) The layout layer helps me a lot with separating the quasi-static frame of the pages from the more dynamic content. See CodeIgniter and layouts? if you like the idea.
(5) Templates are basically HTML with a few PHP snippets.
All my files that contain classes contain one class per file, named the same as the filename (as per http://www.php-fig.org/psr/0/) but I don't use namespaces because I find it hard to make it work with CodeIgniter that doesn't use them.
You can load your models in autoloader, especially if you work on a small or medium-sized project and performance is not critial. I always load all my models with the autoloader in these cases. However, on a bigger project it's more worthwhile to load widely-used models in the autoloader and more specific ones in the controller constructor or the more specific ones even in the actions.
Related
I am building a Laravel 5.3 app that pulls data from a number of potential sources. It's a fallback system with 3 sources:
Database
If not found, source 1
If not found, source 2
All 3 sources are quite simple and will be accessed in the same way, by using the following 2 methods:
function get($id)
function query($type, $string)
I'm aware there is various terminology around the different ways to implement this, but I'm unsure after reading the docs what the cleanest approach is. Should each data source be implemented as a Repository? A ServiceProvider wrapped in a container? I find the docs thorough but also lacking in overall/high level explanations, so any pointers are appreciated.
The Repository Pattern is the following:
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
With that in mind, you can say that Eloquent itself is a much larger implementation of the Repository Pattern, but a Repository nonetheless. Since it's an ActiveRecord implementation, there isn't any real separation between the Repository and Storage mechanisms.
On to your question specifically, Laravel won't really cover the Repository Pattern itself in much the same way it doesn't cover Service classes or Singletons: It's not Laravel's responsibility to teach you these patterns, it's just giving you the means to organize these patterns more easily if you choose to implement them.
All that said, I would agree with you that each data source implement its own RepositoryInterface. From there, you can register your own ServiceProvider that in turn instantiates a custom Service Class whose purpose is to return the appropriate Repository.
If determining the appropriate Repository is light in logic, and is dependent only on the Controller responsible for the alternate data source, you can likely use Contextual Binding and skip the Service Class altogether.
Either way, there's a few ways to skin this cat, but you're on the right track.
Edit: As an aside, if you want to strictly go "by the book" on this, you would probably want to separate out different Storage classes that connect to each data store separately, which you can then query as appropriate. Then your Repository - which is likely housing the same type of data collection regardless of its storage origins - can be responsible for the returned results.
Otherwise, if you want to stick with Eloquent as much as possible, you can look into multiple data connections to house each of your data sets.
I'm trying to understand how Models work in proper MVC.
As far as I know, Models in MVC is where the application logic happens, Models are meat, or back bone of MVC. Views are just presentation, and Controllers are "glue" that asks Models to do some actions, return some data, and pass that information to the View that is presented to the user.
Now, I'm exploring all kinds of different MVC frameworks and would like to understand how to use models in MVC. Symfony 2 is interesting framework as far as Models goes, since there are no Models :)
I have problems grasping some of the features of Symfony2, and where does Models fit in Symfony2 MVC.
By definition, Models are where domain logic, and database actions goes.
So my questions are:
In Symfony2 we have Entities, and Services, are those two Models in Symfony?
What is the difference in Symfony2 Services, and Web Services?
So my questions are where is the Model in Symfony2? Since Model is a layer, composed of Domain Objects, and Data Mappers, then I can assume that Entities are Domain Objects, and Doctrine is Data Mapper, is that correct?
And where do Symfony2 services fit in?
Symfony2 does not have the traditional "Model" part of MVC like other frameworks do. Even Entities/Documents from ORM/ODM Doctrine are not part of the framework itself nor does Symfony2 depend on it.
As Fabien (creator of Symfony framework) wrote on his blog,
"It's up to you to create your model by hand or use any other tool,
like an ORM" ... "I don't like MVC because that's not how the web works.
Symfony2 is an HTTP framework; it is a Request/Response framework."
It was hard for me to understand just reading, but I understood what he meant when I actually started programming in Symfony2.
A service in Symfony2 on the otherhand is just an object that performs a global task. Router, doctrine, logger, mailer are some of the many services that come preloaded with Symfony2. You can access services from any part of your code.
Symfony2 services are completely different from web services. Symfony2 services are meant to be used within your system while web services are meant to be used from machine to machine via REST api for example. Although, I guess you could create RESTful api as part of your service.
"I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework."
I disagree with this statement completely. MVC is definitely suited to the web if you look at it the right way.
1) The HTTP request is received by the Controller.
2) The Controller instantiates the Model (or Models) and activates the relevant method(s) on the Model(s) which each return a result which will usually be an array of data.
3) When the Model(s) have finished the Controller instantiates the View, inserts the data from the Model(s) then activates the method which transforms the data into HTML.
4) The Controller takes the result from the View and sends it back to the client as the HTTP response.
Just because MVC was invented for desktop applications years before the web existed and is therefore irrelevant for the web is a mistake made by people who cannot see the wood for the trees, who cannot see the big picture without fixating on irrelevant details. Each component in MVC has a distinct set of responsibilities, and provided that you create three components each of which fulfils one of these responsibilities - where the physical implementation is irrelevant - then you have MVC whether you like it or not.
I don't know Symfony but I already use other MVC frameworks (grails, codeigniter).
Models (Entities) represents the data and it is possible to define directly in the models some limits used later for the validation. For example, you can define for each attribute if it is required, its length, its pattern, ...
Services is maybe more symfony dependent. Comparing with Grails, Services are the components where you put your business code. In Java EE, it is the Beans. Note that a service can become a web service but it is not mandatory. A Service can also be called by the Controller in order to do some calculation before rendering the view.
I hope that my answer can help.
Shouldn't models just describe data that will be passed from a controller to a view? Doesn't that make models unnecessary in weakly typed languages? In PHP, they are doing DB work in models, but isn't that wrong? As I see it, models are just unnecessary in weakly typed languages...
There are some misconceptions about the term model. Microsoft's MVC3 framework has the concept of a view-model, which is simply the data you use to render your views. This isn't however what the M stands for exactly in MVC. The model includes your business entities. We have thin controllers and fat models, but very thin view models. Our controllers make calls to services that perform business logic, and the controllers never do this logic themselves. We then translate our business entities (our data models) and convert them into a lightweight view model, which can be used for rendering a view.
So to answer your question
Shouldn't model just describe data that will be passed from controller to view?
Then perhaps what you are really asking is aren't view-models unnecessary? I'm not sure why you think this. View model + view makes the result. In PHP it can be helpful to define a class with easily accessible properties on it. This is just sensible for clarifying your expectations and prevents you from calling methods with hideously long sets or arguments. In JavaScript there is no need to define a view model as such, you just push the properties onto a new object and pass it along with your view to your view rendering logic. This is more a reflection of the OO pattern these languages use and not the fact that they are weakly typed.
If you are asking if model is unnecessary, then you have missed the purpose of the MVC architecture. A big part of MVC is that you separate your concerns. Why apply any architecture to your code? I am sure you can find a better explanation of the motivation behind MVC than I can give you.
A model is a useful conceptual tool, even if it's not strictly necessary in PHP to separate it from the DB code e.g. you can have a data object associated with each table that encapsulates some business logic, or define a set of business entities that aggregate the data across tables into domain-specific objects that the controllers can then use, or just have one monster DB object that has all the access functions and returns the entities. This has definite advantages over having DB code directly in use by the controllers:
If you are defining complex data structures that run across DB tables, you don't want to do that in controller code due to the risk of duplication - far better to have a single definition that enforces consistency across the system. Although this can introduce dependencies, having one function/object that defines that data makes it easy to find out where the data is used so you can fix things.
Third party maintenance is far easier if there's one place to go to where all the data structure definitions are found.
It makes unit testing easier if you can swap out the whole model or parts of it and replace it with mock object(s) that will provide test data
It makes controllers lighter and therefore more readable and maintainable
So you could argue that it's not necessary, but it helps a lot.
I've always seen models as a tool to provide data. That means that your controller doesn't ever have to worry about the data source, and if you want to switch from using a database to XML files then you only have to swap out your model.
So long as you have some data provider abstraction. Some Models will do low level validation (tightly coupled to the storage engine - null checks etc) but the controller "should" do all of the business logic/validation.
I personally have a thin struct like class that is mapped to each table (all implementing IDataStruct). This struct, or a collection thereof, is the only thing that moves between the DomainObject and the DataProvider. I can then enforce via my interface what datastruct I should be receiving. This is not a silver bullet but I have found it to work well (Makes things like caching and unit testing quite easy)
I hope this hasn't confused the issue.
I have developed my little own framework, which depends on some model classes. I am using the framework on different projects, but with side effect that project-related changes in the framework are not committed to one "single" framework code, but the changes lost for the other projects.
Now I want to outsource the framework code to one single place and symlink in my projects to that code. So that I am using one model in the framework I have a schema.xml for the framework. In the projects I need also schema.xml files for project-related models. In one project I need to extend generated classes of the framework model.
Is there a way to extend a schema.xml file, so that the propel_generator can generate correct sql file and model classes?
Or is there any workaround / better way for such issues?
I guess that you could use the <external-schema> element and split your schema into the "common" part and the "project specific" part (containing an <external-schema> element pointing to the "common" schema).
See Propel doc : http://www.propelorm.org/wiki/Documentation/1.5/Schema#external-schemaelement
I had a leck of understanding of the terminology "domain models". I wanted to use the models created by propel not only as domain model but also as application model. But this would be wrong.
I will use the <external-schema> feature to divide my domain model into different parts, but I need to create a "application model" layer to encapsulate the domain model from the rest of the world ;)
I'm learning the Zend Framework and it uses a MVC model.
I still have not got my head around what MVC Model, View, Controller is.
What are the three different areas for and what would the program flow look like?
M - Models - are often the biggest source of confusion. These are the parts of your application that do all the 'heavy lifting' - they handle database access, perform the complex application-specific logic and are responsible for most of what your application 'does'. Unlike Views and Controllers, the Zend Framework doesn't have a base class for Models - this is because there's no real consistency in what they do. Some frameworks (like Ruby on Rails) try to present some sort of database-wrapper as a base for Model, but there are many cases (3rd party feed/API, static files, non-persistent calculations, concepts that span multiple tables...) for which this is, at best, a misleading practice. The Model is the part of the application where you're still forced to program and the framework can't really save you from it.
V - Views - are the simplest components here. They should be simple PHP/HTML templates. They're given view objects, arrays, strings, etc. which they then put into a page. There shouldn't be much (if any) complex logic here - loop over these, display this (if defined), zebra stripe this table and whatnot. There's some magic happening with View Helpers (such as the helper that magically renders a Zend_Form), but that's not essential to understanding the overall system.
C - Controllers - In the broadest sense, the controller is responsible for taking user requests, sending them off to Model objects and preparing Models to be handed to the Views. It's the glue that holds everything together. If you're using Zend MVC, you're concerned with 2 controllers - Zend_Controller_Front and Zend_Controller_Action.
Zend_Controller_Front (which you get 'for free' if you use Zend_Layout::startMVC()) is a single point of entry for your application - it handles the raw user requests and translates URLs into an Action to call. There are various places to 'plug-in' to this to handle things like authentication and access restrictions, but, at the core it's just the 'traffic cop' at the front gate directing incoming requests.
Zend_Controller_Action is the base class for actions - essentially an Action represents something your application does (log in, list blog entries, launch an ICBM, order a pizza...), but is not directly responsible for actually doing it. The Action Controllers are pretty boring - they pull values out of forms and URLs, call a few methods on Model classes to actually perform the action and push the results out into the view. As has been said before, they're the 'glue' that holds Models and Views together.
A rough test to see if you're splitting things along the right lines is to envision a major change to your site. A visual redesign would almost entirely be handled in the Views. Moving all your URLs would change your Controllers. Converting from a web app to a GUI app would replace the views and controllers, but your model would still be mostly unchanged. If you rewrite your models, you have a whole new application.
There are several other questions on Stackoverflow that give an explanation of the MVC concept:
What are MVP and MVC and what is the difference?
What is MVC (Model View Controller)?
A very good explanation of the concept can be found on Wikipedia:
Model-view-controller (MVC) is an
architectural pattern used in software
engineering. Successful use of the
pattern isolates business logic from
user interface considerations,
resulting in an application where it
is easier to modify either the visual
appearance of the application or the
underlying business rules without
affecting the other. In MVC, the model
represents the information (the data)
of the application; the view
corresponds to elements of the user
interface such as text, checkbox
items, and so forth; and the
controller manages the communication
of data and the business rules used to
manipulate the data to and from the
model.
In relation to Zend Framework:
models are generally presented by extensions of the Zend_Db_Table class
views are presented as *.phtml files in your defined scripts folder, which are handled by the Zend_View class.
controllers are defined by extensions of the Zend_Controller_Action class.
The Zend Framework has its own very nice Quick Start/Tutorial which especially introduces MVC.
Quote from there:
So what exactly is this MVC pattern
everyone keeps talking about, and why
should you care? MVC is much more than
just a three-letter acronym (TLA) that
you can whip out anytime you want to
sound smart; it has become something
of a standard in the design of modern
web applications. And for good reason.
Most web application code falls under
one of the following three categories:
presentation, business logic, and data
access. The MVC pattern models this
separation of concerns well. The end
result is that your presentation code
can be consolidated in one part of
your application with your business
logic in another and your data access
code in yet another. Many developers
have found this well-defined
separation indispensable for keeping
their code organized, especially when
more than one developer is working on
the same application.
In as few words as possible:
model is the db
view is what you see (the page)
controller is the glue (logic)
Your models know how to access tables containing your data; your views know how to display content; and your controllers glue it together (what view do I show? what model should I use?).