Eloquent Accessor Needs Parameters: What To Do?

Can we use dynamic scope for this scenario?

Apartments::with(['prices' => function($query) use ($startDate) {
$query->where('start_date'...
}])->get();
And then you can calculate sum in view.

Or you can make special method like this:

public function pricesBetween(): HasMany
{
$startDate = self::$startDate;
return $this->HasMany(ApartmentPrices::class)
->where('start_date'...
}
Apartments::$startDate = 'some date';
Apartments::with('pricesBetween')->get();

how about using spatie DTO instead of that native Resource? is that bad practice to use request() in DTO?

Great course, What about a default price for appertmente without sending dates what should do?

You can use type-hint in ApiResources like: /*@property Model $resource */

and then get access to the Model via $this->resource->your_attribute_or_metod.

It's more clear in my opinion.

Please make videos about microservices

why have this kind of logic on a Apartment Model, and not in some higher level layer like Booking (manager or service) class?

Since model is not appropriate place for placing business-logic, I`d rather move that method to service like ApartmentService

What I like to do is using the state pattern to remove logic from Models.

Then it would give something like :


$this->state->priceByDates(..., ...);


Advantages: keep models thin, reusability, external logic bound to a Model can be found in one class.

There's no perfect solution of course!

Thank you Mister, you are a great inspiration to me, furthermore you're someone with human values ❤

Cant we use constructors ?

Possibly a withSum(['AppartmentPrice' => function... the closure would have the query between dates for the appartment_id)

I would strongly recommend using an action or service class, such as \App\Actions\PriceCalculator::handle(Apartment $apartment, Carbon $from, Carbon $to): float. It's not ideal for the apartment model to be aware of the price calculation process, which is more of a business logic concern. By separating this logic into a dedicated class, you can improve the overall structure and maintainability of your codebase.

I don't if it's valid in your case but sometimes it's a good way to use local scope. In your api you call the relation prices() then you link a scope that calculate prices for specific dates and execute the query.

Hey Povilas! Love your content.
I want to ask you shortly if you can make an article let's say what's requirements for setting a macos for Laravel devs, I mean instead of xampp what to use for having an apache and etc. I think that would be really helpful , don't you think so? There is not a lot of stuff out there.
Thanks and have a wonderful day!

I think the better term will be "getter" instead of method. As we are not relying on the accessor we are creating our own getter method.

I would make separate action class CalculateApartmentPriceByDates for example, because by adding more and more methods to this model I will end up with a big mess.

What you will do if between start<>end intersect different price periods, what actual price will be? )

Thanks for this Sir. A question please. Instead of $this->calculatePriceForDates() in the controller, we can also do Apartment:: calculatePriceForDates()
Is this correct?