Support the ongoing development of Laravel.io →
Eloquent Architecture
Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

If you are using the repository design, you could add isClockedIn($id) to your UserRepository class.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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?

Last updated 2 years ago.
0

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);
    }
}




}
Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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!

Last updated 2 years ago.
0

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.

Last updated 2 years ago.
0

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.

0

Sign in to participate in this thread!

Eventy

Your banner here too?

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.