ASP.NET Web API打破了Repository / Services模式

Question

I am new to building web APIs and have reached a point where I could use some direction. So lets say for example that I have a Product model and a Attachment model which look something like this:

 public class Product
 {
     public Product()
     {
        Attachments = new List<Attachment>();
     }
     public int ID { get; set; }
     public string Name { get; set; }
     public List<Attachment> Attachments { get; set; }
 }

 public class Attachment
 {
     public int ID { get; set; }
     public string Name { get; set; }
 }

Notice that the Product model has a property list of type Attachment . Is is bad practice to utilize the AttachmentRepository to fill this property when I am initializing the Property object in the ProductRepository class?

So in the ProductRepository I would do something like this:

Product product = new Product
{
    ID = SomeId,
    Name = SomeName
    Attachments = AttachmentRepository.GetAttachments(SomeName)
};

Is this poor design and I am approaching this incorrectly? I am not planning to create a Controller for Attachment since there would be no use case for getting an attachment without the context of a Product .

Answer 1

"I am not planning to create a Controller for Attachment since there would be no use case for getting an attachment without the context of a Product."

How about the inverse? Would you ever want to get the product without Attachments?

I find methods that try to do too much not as reusable , because if I am getting a large number of products and am not interested in attachments, I don't want the overhead of also getting attachments for all of those products. I then regret the design(whether it was mine or a colleague's), adding a new method just to get Products.

In my controller I would have the call to GetProduct and then a call to GetAttachments. This would allow you to mix-match these as needed.

Another approach would be to do this in the Products repository, have a method that gets just products(GetProducts), and another GetProductsWithAttachments method that calls GetProducts and also calls GetAttachments. Or you could of course have a boolean parameter for , includeAttachments = false) . I don't like my DB layer getting that messy. I let the Controller be the place to pull it all together.

I would also probably not even have Attachments property in Products model, but instead have a ProductResponseModel specific to the controller that is the analogy of a ViewModel. It would be the one with both the product information and the Attachments property, and you would populate it from the results of calling the two seperate Repository methods.

If you do it all at the DB layer, and your Product model from the DB layer has an Attachments property that is only populated when you call GetProductsWithAttachments, then your Product model is half filled . Add many other similar properties over time, and you've got a really confusing model because sometimes only some of its properties are populated based on which method of the repository you called. Developers have to start digging into the repo methods to figure out what populates what. If you add Promotions to a Product will you have a GetProductWithAttachments, GetProducts, GetProductWithPromotions, GetProductWithAttachmentsAndPromotions? You can begin to see how this can get out of hand, and some default parameters would be better if you really want to bake this into your repository. However:

Recommended: Composition in the Controller

That's why my preference is to let the controller orchestrate the whole thing. Call repo methods separately within the controller. Not sure if your using a REST style or what in your Web API controllers, so just consider this pseudo code:

public class ProductController: ApiController
{
  public ProductResponseModel Get(int productId) 
  {
     var model = new ProductResponseModel{
        Product = ProductRepository.Get(productId);
     };
     model.Attachments = AttachmentRepository.GetList(model.Product.Name);

     // I could have flattened out the Product into its properties instead of having a model.Product,
     // but that can be a maintenance problem and requires something like AutoMapper to manage well
     return model;
  }

}

public class ProductResponseModel {
  public Product Product {get;set;}
  public IEnumerable<Attachment> Attachments {get;set;}
}

The ProductResponseModel is an example of composition. It creates loose coupling with the DB layer, so you are free to mix and match, ie compose models of what data you need for each API controller. The ProductResponseModel itself is not very reusable, maybe only within that controller. Another controller that needs a different combination of Product data will have its own SomethingResponseModel and call seperate Repository methods to populate it. Even though we don't get to reuse our *ResponseModels, that's not a big loss because they are simple POCOs. Getting reuse out of our repo methods is more important, and saving them from becoming more complicated than they need to be. Additionally we still have your simple model such as Product and Attachment that are part of the repository layer, so that everyone calling the repo is speaking the same language and using the same common types. So don't make the mistake of having your Repo layer return a ProductResponseModel. It's your controller's job to take the Product and populate the ProductResponseModel .

I use the naming convention *ResponseModel because if I have a complex parameter for the action method also, then there is a *RequestModel as well. Ie Request/Response. And if I have an API method that is more RPC style than REST style, such as maybe ProductController.DiscontinueDistribution its return might be very specialized and so I'd have a ProductDiscontinueDistributionResponseModel. Still these are all simple POCOs just like ViewModels in MVC.

Answer 2

If your not using EF or another ORM, then your Product object probably shouldn't contain a list of Attachment objects -- that should be a construction of (like @AaronLS said) some form of DTO akin to a viewmodel in MVC.

Something like:

public class DTOProductAttachment
{
    Product Product { get; set; }
    List<Attachment> Attachments { get; set; }

    public DTOProductAttachment(int id, string name)  // <-- Product ID, Product Name
    { 
        Product = ProductRepository.GetProduct(id); // <-- Product ID
        Attachments = AttachmentRepository.GetAttachmentsByProductName(name); // <-- Product Name, or ID or whatever joins your tables
    }; 
}

... And I think the importance here is, your "objects" Product and Attachment should be reflective of your database design. Your repositories should act in a way that is intuitive of your architecture.

For example, the AttachmentsRepository.GetAttachmentsByProductName() method above is completely intuitive if Name (Product name) is a foreign key on your Attachments table (probably should be Product.ID but I'm running with your example above.)

But, these decisions are relative to your design requirements/goals. For example, if an Attachment object had a one to many relationship with another object, let's say AttachmentChild , then it would be reasonable to assume you might want to select all of the AttachmentChild objects by Product Name or ID.

... In this case, adding a method like AttachmentChildRepository.GetAttachmentsByProductName() seems a little fishy.

For salience, you might include the Product Name (or ID) on the AttachmentChild object, even though it's not technically necessary.

I hope this helps.