views:

265

answers:

2
+1  Q: 

DDD / Repository

Hello,

I am very new to DDD. My SQL table contains a list of styles, every style has colors and sizes. Now, I am working on an application, where the user will see three dropdownlists, one for style, one for the color and one for the size. Now initially these dropdownlists are loaded with the distinct values. The user is then able to select a style and the system will then able to find all colors/sizes for that selected style. The user can do the same with the color and it will load the styles that match the selected color and the sizes. You get the idea.

These are my basic requirements. Now I was thinking to create a repository for the styles (StyleRepository) and have it load all styles, and when required load the child colors, and child sizes.

However as described in my app, I will also need to load the distinct colors or sizes. Now is it recommended to create three repositories instead StyleRepository, ColorRepository, SizeRepository or would I create a totally different Repository?

As said I am fairly new to this and would appreciate your suggestions.

Thank you

A: 

As colors in your case are actual colors used by styles, not just abstract color list (like in painting application), I would go with StyleRepository and addeed method like GetAllUsedColors().

alex
Thanks for your comment. Would I then add methods like GetColorsByStyle, GetSizesByColor etc..? Also would the Color property in the lets say my Style class be a list of Color or just a string? Sorry of the questions sound simple :(
vikasde
As a general rule, you should prefer 'Value' objects (i.e. Color, Money) to primitive types (i.e. string, decimal).
alex
OK, however if my Style class looks like this:class Style { .... public virtual Color Color { get; set; } .... }Is the Color property supposed to be an array?
vikasde
Also how do I reply? Using the comments box gives me only 300 characters :(
vikasde
If style associated with only one color then it will be a single value, not array. However, if you need to get the list of colors frequently, you may consider having AvailableColors, or AllowableColors property on your business object for validation and presentation.
alex
I need to retrieve the distinct colors and sizes as well, regardless of whether a style is selected or not.
vikasde
Dropdown is not "domain" concept, it is "presentational". In addition to repositories, you can have services, that provide helper methods like "GetAllDropdownValuesForPresentationTechnolofyX()" and "GetAllImagesOfAvailableFabricForPresentationTechnologyY()"
alex
+2  A: 

Style appears to be your root aggregate object. That's what you build your Repository around.

Since each Style has a specific subset of Colors and Sizes that are allowed for that style, each Style should contain a list of Colors and Styles.

public class Style
{
   public IList<Color> Colors { get; set;}
   public IList<Size> Sizes { get; set;}
}

Your Repository is then going to have a FindAll() method to return all the Styles. Each Style has its own list of Colors and Sizes, so no need to hit the Repository again to get those. When the user selects a specific Style from a dropdown (hopefully you've bound the Style object) then you can just get the list of Colors and Sizes from the selected object and populate the other Dropdowns.

When a user chooses a specific Style, Color and Size, then I would assume that gets saved in a separate class, like a SelectedStyle class, which only contains one Color and Size property.

public class SelectedStyle
{
   public Color Color { get; set;}
   public Size Size { get; set;}
}
Chris Holmes
Thanks Chris. Would I also have a FindAllColors() or FindAllSizes()?Please note that I should be also able to see all distinct Colors and Sizes and if I choose my Color in the dropdownlist, then I should see *all* styles and *all* sizes for that given Color. Makes sense?
vikasde
A truly agile question... the requirements keep changing. I would have to say now that you don't need a repository at all. You need something else, like a presentationmodel, because your logic is based around showing lists based on the selection of another list.
Chris Holmes
hm.... I was pretty certain that I need a Repository. A higher level Repository would not solve it? Something like a SKURepository?
vikasde
No. Because what you're asking for has nothing to do with a Repository. You're logic is based around how to show things based on certain criteria, and that's a presentation-level concern. Repositories should act like facades - they should appear as a collection.
Chris Holmes
If I were you, I'd just query for Styles, Colors and Sizes separately, through a service of some kind. Then I'd handle the logic in a presentationmodel. No repository necessary. You have no real domain objects here.
Chris Holmes
Ah. Gotcha. I guess I should read Evans book about DDD. How do you define a domain object?
vikasde
A domain object has some kind of business meaning, and it's typically going to be a variant. Your Colors/Styles/Sizes are invariants. They're just constants really. This is probably a longer conversation. Happy to converse via [email protected].
Chris Holmes