I am currently in the process of learning Laravel 5 by doing a small project. I come from CodeIgniter and have some programming experience in other languages as well.
For this project I have a few Eloquent models setup;
Exercise -> has many variations
Variation -> belongs to exercise
User -> is creator of exercise and/or variation
I am using Larasponse and have written some transformers for each entity, as I want to create a flexible API.
To use 'eager' loading I have been playing around with Fractal and the 'ParseIncludes' function, and created a ApiController that handles this for you. For each controller that extends the ApiController you can set $IncludeOptions that relate to that specific resource, and passing that to a function to get eloquent eager loaded relations.
So far it works, but I was wondering if I am doing something really stupid or if there is a better/cleaner way to implement this into the ApiController and it's child-classes..
https://gist.github.com/EdwinMeijne/1fd103fbf8f903ce58bc
Care to take a look?
Related
I wonder about the route leading to the welcome-page in my project. You reach it with the '/'-route .
Where should the method handling this route be and what is the correct structure behind it?
I get two ideas spontaneously:
Make a model named something like Home and put the method in HomeController
(Con: I thought all modells should be represented in DB?)
...
Make only a controller named HomeController, no model
(Con: Feels wrong to have a controller for a modell that does not exist?)
What is correct?
I can't comment so I'll leave it here.
Both Model and Controller are just Class. If you take a look at your HomeController and your User.php model you'll see they extend Controller and Model Classes, respectively.
As many said there is no need to have 1 to 1 relationship between Controllers and Models.
Invest some time to learn basics of OOP and you will see that you can have as much classes as you want, and there are many ways to relate them. Some of the Classes are Controllers, some are Models and some are something completely else, like Exceptions. But at all times keep in mind that, in the end, they are just Classes implementing some interface, using some traits, and extending other Classes.
It's worth to do this at the start of your learning process. It will steepen your learning curve a bit but in the long run it's well worth it.
You don't need a model for each controller or vice versa, just add them as needed according to your application: need CRUD actions or other interaction with your model. Try creating a WecolmeController as the HomeController is the default one for after login features (or change it accordingly if needed).
I am looking for a way to add few custom methods which will be used in all models. I can imagine 3 ways of doing it :
Adding custom method to main Eloquent's Model.php class file(I want to avoid doing this as this is a core file)
Creating a custom model class with required custom methods, which will extend to eloquent's Model class and all the models in the project will extend to custom model class.
Adding a trait which will have my methods and include it inside all models
However, I want to do it more efficiently and best way possible. Is their any other way to do it?
PS I am using laravel 5.2 as its an old project.
Based on the comment discussion and adding my experience in Laravel I would suggest you to go either with #2 or #3 approach as #ceejayoz have specified in the comments
first one is definitely a bad approach as you need to modify the core which is not at all a good practice. Second and third are both good approaches.
But, before that you need to check your requirements if literally all models (including any future ones your app will ever have) need the extra functionality, however you can use traits for all models.
If I have the choice probably I will go for traits over custom models as traits are relatively simple then custom models
I'm wondering whether it is possible/advisable to use instances of a laravel model instead of using the Facade. Why all this trouble? I have a model which will be used with many tables, and i want to be setting the model's table automatically using the constructor. Is it possible/advisable, or what is the best approach of achieving the same end?
I have researched around with no much success.
UPDATE
THis is the scenario: an exam system, where different exams are "created". after an exam is created, a table is created in the database under the name Exam_#, where # is the ID of the exam. I want to access all exam from one model: Exam, but you see the particular table the model is to use can vary significantly, so we cannot set the table variable statically. The model shall not know the table it will use until it(the model) is called. So thats why i was wondering whether i can be passing the ID of the exam when i am calling the model or something like that. I hope my question is now more clear.
At the end of this, Laravel is still PHP... Anything you can do in PHP can be done in Laravel.
is (it) possible/advisable to use instances of a laravel model instead of using the Facade?
You can achieve exactly the same results using an instance of the model as you would using the static facade.
$user = User::find(1);
$user2 = new User();
$user2 = $user2->find(1);
Both instances of the above model contain the same results.
Is it advisable? I really don't like the static facades at all, they bring with them more trouble than they are worth, especially when it comes to testing (despite being able to mock them, they create tight coupling where most of us need loose coupling). My answer to this would be: don't use the facades at all.
What is the best approach of achieving the same end?
As #JoelHinz suggested, create a base model with common properties and then use the models as they are intended. i.e. ONE table to ONE model and create the relationships between them. Don't use the same model for multiple tables, this is not how Laravel models were intended and you will lose a lot of the power Eloquent provides by taking the approach you mentioned.
Updates from comments
To get you started with testing in Laravel this is a good end to end tutorial Tutsplus Laravel4 + Backbone. Ignore the backbone part, what you're interested in is the testing parts that start about a 1/3rd of the way down the page. This will get you testing controllers straight away and introduce you to the repository pattern to create testable DAL structures.
Once you get the hang of writing tests, it becomes very easy to write a unit test for anything. It may seem like a scary subject, but that is purely down to not understanding how it works, it really is quite simple. Take a look at the PHPUnit documentation as well, it is an excellent resource.
I am now at the fun part of my journey in building an MVC application. I have spent the last 3 weeks researching architecture, ONION specifically, and learning about IOC/DI and such.
So my question is this:
What is the best way to implement ViewModels? I have seen some terrible examples so far.
I recommend reviewing this article which outlines different 'tactics' for handling view models.
http://blogs.msdn.com/b/simonince/archive/2010/01/26/view-models-in-asp-net-mvc.aspx
Some recommendations I can give you for view models is:
Base them directly on your view & what the user interface needs,
Prefer creating custom view models for seperate pages instead of generalizing them to be re-used across different views.
Keep them simple & flat, don't go overboard with inheritance etc.
If you are mapping from database models, adopt an existing method for mapping between your models and view models such as AutoMapper
Consider using dynamic in some cases, its more flexible and can have less friction.
What are the best practices for implementing models in the MVC pattern. Specifically, if I have "Users" do I need to implement 2 classes. One to manage all the users and one to manage a single user. So something like "Users" and "User"?
I'm writing a Zend Framework app in php but this is more a general question.
The model should be driven by the needs of the problem. So if you need to handle multiple users, then a class representing a collection of Users might be appropriate, yes. However, if you don't need it, don't write it! You may find that a simple array of User objects is sufficient for your purposes.
That's going to be application and MVC implementation specific. You might well define a class collecting logically related classes, or you could define a static register on the user class. This is more of an OO question than MVC.
I'll second Giraffe by saying the use of included collections is almost always better than trying to write your own.
But I think your original question could be reworded a little differently... "Do I need a separate class to manage users other than the User class?
I use a static factory class to build all of my users and save them back to the database again. I'm of the opinion that your model classes need to be as dumbed down as possible and that you use heavy controller classes to do all of the work to the model classes.