Okay, so continuing where we started, there are a few improvements we can make to organize our code better. We will follow the single responsibility principle here to help us improve the code structure so we can easily extend it without changing the same files over and over again whenever a business need arises. We want smaller, more specific classes with specific names that exactly tell us what the responsibility of the class is. We started with the interface segregation principle, and that gave us a nice structure to have small and specific classes. Remember the Pioneer class, the Wire class?

to have small and specific classes. Remember the Pioneer class, the Wire class? Both of them have very specific small interfaces and are very readable and easy to understand. And that's a good start, but we still have some improvement points to make. Our Wire and Pioneer classes have two reasons to change right now. The first one is due to changes in the database, which we can notice here. And this is fairly simple. If it stays like this, you can definitely handle it here. But in reality, we might have a lot more complexity than this, and over time, this would get much more complicated and harder to navigate through, so it's better off in a different place.

But in reality, we might have a lot more complexity than this, and over time, this would get much more complicated and harder to navigate through, so it's better off in a different place. The second reason to change is changes in the business logic. So what our Service class does, basically, it outlines the business logic that we have, and it's translating it into specific actions that the code needs to do. So we want to keep that. The business logic's place is in the Service classes. The database's place is outside of the Service classes, within repositories. To transfer the responsibility for the database work to repositories, we need to start by creating a repository directory.

To transfer the responsibility for the database work to repositories, we need to start by creating a repository directory. I will do that here in the app folder. So, repositories, and then, inside the repositories, we want to create a separate repository for all of the payment methods that we have. So first, we have WireRepository, and the namespace is App\Repositories. Let's wire. Let's see. From here, I need a method to get the fields, a method to get the values, store, delete, and makePrimary.

From here, I need a method to get the fields, a method to get the values, store, delete, and make primary. So let's just create those. Now, the first step would be to transfer all of the database logic from a service class to the repository class. And what I have over here, for example, the store, I will just take this part, move it to the repository. I need to encode this model there. Then, the getFields, which you remember, we had it implemented over here as an array, I will just copy that, paste it here.

Then, the getFields, which you remember, we had it implemented over here as an array, I will just copy that, paste it here. In reality, this is a database structure, so imagine that we have some database structure in the background for this, and I will just cheat a bit with this method. Okay, now we'll leave everything else blank as we did before, assuming that it's implemented already and it works properly. Now I'll need a scene for Pioneer, and let's just copy this again, we'll need Pioneer here, we'll need to include it up here. Okay, and then for the getFields method, this is what we have. Okay, so we have removed all the database logic from the service classes, moved it to

Okay, and then for the getFields method, this is what we have. Okay, so we have removed all the database logic from the service classes, moved it to repository classes. Now we need to include these repositories in the services and use them whenever we want to handle the database logic. I will just start by referencing the repositories in both of the service classes and using them as complete implementations, we'll circle back to this later and see how we can improve it further. So we have App\Repositories\WireRepository. Great, let's just create a constructor here.

So we have App, Repositories, WireRepository. Great, let's just create a constructor here. Now what do I want to do here? In the getFields part, just get the fields from the repository, perfect. All the methods will do the same. Over here, instead of calling the model now directly, I will just call the relevant method in the repository. Okay, so getFields, we don't want this. Just first reference the repository and everything will be simpler. Now we need the constructor, and now fields will return, getFields from the PioneerRepository.

Just first reference the repository and everything will be simpler. Now we need the constructor, and now fields will return, getFields from the pioneer repository. And here, instead of calling the model directly, again, I will use my pioneer repository. Okay, just remove the model because we're not using it anymore. And now this should be working just with the adjustment that we made. So notice that we didn't change anything in terms of the functionality, the features that we have. We're just restructuring the code in a way that it will allow us to scale much more easily in the future. This is the single responsibility principle in practice.

in the future. This is the single responsibility principle in practice. So our service classes are now much leaner. They have only one responsibility, which is to handle the business logic. So we don't have any information about how the WireRepository is handling the store or how the WireRepository is getting the fields that we need to display. It just knows that this is an action that we need to perform in the background, and I know what to rely on to handle that action. Anything other than that is not a responsibility of the service class.

Anything other than that is not a responsibility of the service class.