How to organize Rest api consuming project following helix principles

Question

I am building a sample asp.net application for learning purposes which should follow helix principles. The aplication is going to consume restful api results (searching car models). I have already created a Feature project (there i plan to connect to the api using HttpClient and later use it from the CarsController in the web application project). I need to create two methods which will call to different api endpoints:

• first will be searching for cars by name (it can be SearchCars(string name))
• second will search for given car by its id (it can be FindCar(string id))

those two possibilities are supported by different api endpoints as i mentioned above. Since i am learning helix (also learning SOLID) i am not sure where should i put this functionalities - i try to choose the correct between Repositories and Services folders in my Feature project. Thank you in advance for any tips/opinions.

Answer 1

If we are talking stricktly about sitecore data, the Repository classes usually should only contain methods which deal with getting information from sitecore directly, like populating the Car field values, getting Car categories or reading children items and so on. You can take a look at the habitat example here.

Then you would have a CarService which will handle the building of the search query, like specifying the different Filters and the index. Then for example if you need to return a list of CarItems from the SearchResults you would use in your Service _carRepository.GetCarItems(search.Document). You can take a look at the habitat example here.

Your CarsController will call the SearchCars and GetCar methods implemented in the CarsService. You should also take a look at the post Sitecore helix pattern and where to place your business logic.

I assume that you will have other projects which will use searching by a specific entity aswell. I would recommend having a Foundation generic project which handles the same functionality in order to not have it duplicated in multiple places.