o_19mgorv9t13a3ko71fev19l81mqa.pdf

Figure 7-4. Creating the Product class
You are already familiar with the definition of the Product class, as I am going to use the one you saw in the previous
chapters. Edit the Product.cs class file so that it matches Listing 7-3.
Listing 7-3. The Contents of the Product.cs File
namespace SportsStore.Domain.Entities {
}
public class Product {
public int ProductID { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public decimal Price { get; set; }
public string Category { get; set; }
}
I am following the technique of defining my domain model in a separate Visual Studio project, which means that the class must
be marked as public. You do not need to follow this convention, but I find that it helps keep the model separate from the
controllers, which is useful in large and complex projects.
Creating an Abstract Repository
I need some way of getting Product entities from a database. As I explained in Chapter 3, the model includes the persistence
logic for storing and retrieving the data from the persistent data store, but even within the model, I want to keep a degree of
separation between the data model entities and the storage and retrieval logic, which I achieve using the repository pattern. I will
not worry about how I am going to implement data persistence for the moment, but I will start the process of defining an
interface for it.
Create a new top-level folder inside the SportsStore.Domain project called Abstract and, within the new folder,
a new interface file called IProductsRepository.cs, the contents of which Listing 7-4 shows. You can add a new
interface by right-clicking the Abstract folder, selecting Add New Item, and selecting the Interface template.
Listing 7-4. The Contents of the IProductRepository.cs File
using System.Collections.Generic;
using SportsStore.Domain.Entities;
namespace SportsStore.Domain.Abstract {
public interface IProductRepository {
}
}
IEnumerable Products { get; }
This interface uses IEnumerable to allow a caller to obtain a sequence of Product objects, without saying how
or where the data is stored or retrieved. A class that depends on the IProductRepository interface can obtain
Product objects without needing to know anything about where they are coming from or how the implementation class will
deliver them. This is the essence of the repository pattern. I will revisit the IProductRepository interface throughout
the development process to add features.
Making a Mock Repository
Now that I have defined an abstract interface, I could implement the persistence mechanism and hook it up to a database, but I
want to add some of the other parts of the application first. In order to do this, I am going to create a mock implementation of the
IProductRepository interface that will stand in until I return to the topic of data storage.
168