isClockedin() function would be in a controller. I would keep a UserController separate from a TimeCardController. I am sure that when you execute the isClockedin function the redirect will most likely be an updated status. If you are using routes then you would just point your action URL toward those routes. I am not sure if this helped, but if so then good. Yii and other MVC frameworks are used to using fat models and skinny controllers. However, it seems the opposite with Laravel.
Thanks for the reply swgj19. You say to put it in the controller, but I'm going to need to access that information in many different places, so a controller doesn't make sense. A controller (from my understanding) should just be a transport layer.
If you are using the repository design, you could add isClockedIn($id) to your UserRepository class.
Repositories should be concerned only with persisting and retrieving data - knowing the state of a user is not persistence logic and shouldn't be in a repository.
For simpler projects I would recommend keeping the same organization you used in Yii - put that logic in the model.
For a more complicated project I would put together a TimeclockService (or similar - names are hard) that accepted a User object and a UserRepository in it's constructer. Use the user model to get state information about a user however you need to and the repository to persist changes to the user's data as necessary.
abbajbryant said:
Repositories should be concerned only with persisting and retrieving data - knowing the state of a user is not persistence logic and shouldn't be in a repository.
For simpler projects I would recommend keeping the same organization you used in Yii - put that logic in the model.
For a more complicated project I would put together a TimeclockService (or similar - names are hard) that accepted a User object and a UserRepository in it's constructer. Use the user model to get state information about a user however you need to and the repository to persist changes to the user's data as necessary.
This is the best answer. The controller is about the worst possible place it could be, and while a repository isn't terrible, checking to see if a user is clocked in isn't really related to persistence. Given that code is relevant strictly to your domain logic, the model is actually the best place for it.
This is the best answer. The controller is about the worst possible place it could be, and while a repository isn't terrible, checking to see if a user is clocked in isn't really related to persistence. Given that code is relevant strictly to your domain logic, the model is actually the best place for it.
Thanks for the replies. Nice to see the community here is so welcoming.
I thought the Eloquent model was strictly for mapping data? Am I over-thinking it?
Personally if it's something simple I would leave it on the Model.
Otherwise you could have maybe a TimeClock class which handles this so you can do something like this
class Timeclock
{
protected $timeCard;
public function __construct(TimeCard $timeCard)
{
$this->timeCard = $timeCard;
}
public function userClockedIn(User $user)
{
$lastTimeCard = $this->timeCard->where('user_id', $user->id)->first();
return is_null($lastTimeCard->out);
}
}
}
Yes, I think you're over-thinking it.
I feel that many people try to avoid putting methods in their models these days. I don't know exactly why, but I guess it's because they were told not to violate SRP .
If your User object doesn't have a 'hasMany' relationship with your Timecard object, then you should create a service to handle 'isClockedIn' logic. If you have a 'hasMany' relationship, it totally makes sense to have 'isClockedIn' in your User object based on your description. In fact, if you create a service class for this simple case..you're creating anemic models.
it's pretty simple method.
class User
{
public function timecards()
{
return $this->hasMany('Timecard');
}
public function isClockedIn()
{
$lastTimeCard = $this->timecards()->orderBy('id','desc')->first();
return is_null($lastTimeCard->out);
}
}
The fact that you're using an ActiveRecord implementation of ORM such as Eloquent means that your model (Eloquent) is fully aware of your persistence layer. There's no harm to use query related methods in your model as long as you don't mix up other objects in your model.
moon0326 said:
Yes, I think you're over-thinking it.
.....
The fact that you're using an ActiveRecord implementation of ORM such as Eloquent means that your model (Eloquent) is fully aware of your persistence layer. There's no harm to use query related methods in your model as long as you don't mix up other objects in your model.
This totally satisfies my (new) concern about putting things in models. Thanks to everyone for taking the time!
aarondfrancis said:
moon0326 said:
Yes, I think you're over-thinking it.
.....
The fact that you're using an ActiveRecord implementation of ORM such as Eloquent means that your model (Eloquent) is fully aware of your persistence layer. There's no harm to use query related methods in your model as long as you don't mix up other objects in your model.
This totally satisfies my (new) concern about putting things in models. Thanks to everyone for taking the time!
To add to that a bit, in a purely architectural sense, yes Eloquent should be primarily for mapping data, and you should use an entity class to store all of your business logic. But unless you're working with a pretty large application where that kind of thing is very important, it's usually not worth it.
This is the best answer.
You can also use the TimeClockService to do other things like clock a user in, for example.
abbajbryant said:
Repositories should be concerned only with persisting and retrieving data - knowing the state of a user is not persistence logic and shouldn't be in a repository.
For simpler projects I would recommend keeping the same organization you used in Yii - put that logic in the model.
For a more complicated project I would put together a TimeclockService (or similar - names are hard) that accepted a User object and a UserRepository in it's constructer. Use the user model to get state information about a user however you need to and the repository to persist changes to the user's data as necessary.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast