I'm doing a simple MVC web app that is supposed to do different queries to a SQL database. I'm using Symfony 4 as a framework, mostly to take advantage of its routing features.
I know I could take advantage from Doctrine but I was wondering: if someone wants to use PDO instead of Doctrine is it possible to do so and how should it be implemented. Should I make a Database class with PDO that I could pass on to another class?
Yes, you are not required to use doctrine at all. You can just define your own service with required functionality.
But maybe you could use DBAL which is lower layer used by doctrine to handle creating queries (but doesn't include any ORM functionality).
Related
For a project at work I'm creating an API in Laravel. I wanted to use MongoDB as database driver which is new to me. So I want to use Eloquent with MySQL in the beginning and when I'm confident enough switch to MongoDB.
I was reading some tutorials about the repository pattern in Laravel and saw that some returned an eloquent model, like this one. It seems to me that when returning a model on for example create($data), you're limited to database drivers which are suitable with Eloquent. I was wondering if it is a good practice to return an eloquent model. Because if I want to use MySQL for now and in the future MongoDB (without the Laravel MongoDB package), I need to rewrite some code in the controllers because the use the eloquent models instead of an array (for example). Maybe a 'wrapper' between the model and your code is a possibility? Any good recommendations, tips or thoughts on this?
If you're wondering why I want to use MySQL for now and later switch to MongoDB, the reason is there is a time limit on the project. I'm still learning Mongo. So to fulfil the needs of my employer, I'm not using MongoDB until finishing the first version / prototype.
If you use eloquent and its methods, you should be good. Just do not use the DB::raw() method as it may break your query if it does not match the DB engine you are currently in.
I wrote a repository pattern article if you want to look at it (with tdd).
But if you really want future proof, you can mix Doctrine w Laravel since Doctrine is a Data Mapper Pattern. Link
With laravel-doctrine package, you persist the data in your db engine that you prefer.
Is something like laravel-mongodb good?
Extending Eloquent to use MongoDB instead of MySQL.
there is a Repositories layer in my laravel project. I am a freshman about laravel. I can not fully understand the advantages of this layer. My colleagues tell me that it is purpose to lower the coupling of the codes. Obviously, it is true. But I also look forward to your comments.
Using repositories, we can create complicated query and isolated it behind a readable method name. The coupled used, when using eloquent, we must put the record name in eloquent query, but using repositories, we can hide the record name and put in the other place. So that is give some security reason too. Also we can use for grouped some entities for authoritative users. Repository allows abstraction from data provide engine.
This article can help you.
I'm working in a project in Symfony 3.0.1 that use five databases with DBAL as data access layer. I always worked in Symfony with ORM and I always used the next MVC model:
Data access:
CONTROLLER -> REPOSITORY (the queries goes here) -> ENTITY
Display results:
CONTROLLER -> render($view,$params) -> VIEW
This model allow short and simple controllers, but now I'm using DBAL so I can't use repositories.
The question is:
How can I achieve a similar model by using DBAL? In others words, Where should I put the queries?
Should I use services instead of repositories?
Note: I only use the select statement in that databases.
Thanks in advance!
You don't need an ORM in order to use entities.
Likewise, you do not need Doctrine to be able to build repositories once a repository is a implementation of design pattern:
Repository
Mediates between the domain and data mapping layers using a
collection-like interface for accessing domain objects.
Read more
Even though you can't use Doctrine ORM you still can to design POPO classes against an abstract model class or/and model interface.
You could inject DBAL Connection object for each model/entity via construct or setter method. After creating repo classes is easy. Returning collection objects, hydrating items or using raw arrays is up to you.
Edit #1
I have added a real worl exemple I have used in the past (few years ago), look:
https://github.com/felipsmartins/misc-and-code-snippets/tree/master/php/model-exemple/src/AppBundle/Model
Edit #2
Regarding services, it would much better if there is specialized and well defined models (as opposed to Anemic Models) working together inside a service which coordinates the whole transaction, in this case it would be what we know by Unit of Work (see Unit of Work Pattern)
I'm using Elasticsearch in my job, and I'm considering to connect with Elastic using FOSElasticaBunble as an intermediate abstraction layer.
But I have a doubt, reading the documentation, it seems that is possible to map types to Doctrine Entities, but it also seems that is required to combine Elasticsearch with another persistence layer, like a SQL DB, or MongoDB.
Is possible to use Doctrine Entities without any extra persistence layer aside from Elasticsearch?
Thanks for your attention.
All,
I have a PHP application written in Zend Framework with MVC style. I plan to use Zend_DB to connect to the MySQL database and process queries. I am looking for a wrapper class which makes it easy to use Zend_DB class. This wrapper class will have a constructor that connects to the Mysql db using Zend_DB. It will also have a method to return a singleton instance for each and every db connection made.
Something like:
$pptDB = PPTDB::getInstance();
$pptDB->setFetchMode(PPTDB::FETCH_OBJ);
$result = $pptDB->fetchRow('SELECT * FROM bugs WHERE bug_id = 2');
echo $result->bug_description;
Where class PPTDB extends Zend_DB
Is this something feasible to have? If not, how ls would you use Zend_DB in a major application?
Thanks,
AFAIK it is possible to use Zend_DB as a standalone (well, all classes in that package should also be available of course), but if you're not using the models there is little to gain from is. If you're only interested in the database abstraction I'd recommend PDO, if you want a Zend_DB wrapper Reflection can give you a nice list of properties / functions you can choose to override or not.
http://nl2.php.net/reflection
You should create adapter using Zend_Db::factory() and than use it in Zend_Db_Table_Abstract::setDefaultAdapter(). Then you can get your adapter wherever you want using Zend_Db_Table::getDefaultAdapter() or $table->getAdapter() :)