Discussion on: Kentico Xperience Design Patterns: Multiple Types Per File

[themarkschmidt]

Good article, interesting ideas. It would be good to see how you name these files and where they live in the folder structure.

[Sean G. Wright]

Thanks for reading Mark!

I typically name the file after the 'primary' type.

If I do include multiple types in a single file, it's because they are all directly related.

Example:

public class ProductDetailsViewModel
{
    public ProductViewModel Product { get; set; }
    public IEnumerable<RelatedProductViewModel> RelatedProducts { get; set; }
    public IEnumerable<ProductPromotionViewModel> Promotions { get; set; }
}

I could put all 4 of the types referenced above in separate files, but they are all directly related (referenced in the ProductDetailsViewModel public type definition), so instead I would create a file ProductDetailsViewModel.cs and define all those related classes there.

If it then turns out that the ProductPromotionViewModel is used in another View, I might extract that out to a higher namespace/folder since it would no longer be completely 'owned' by ProductDetailsViewModel.

On the other hand, if all these types were only used by the ProductDetailsController, I would be inclined to move all their definitions into the ProductDetailsController.cs file.

As an example for file organization in folders/namespaces, if I have an ImageViewModel that I use across all features / pages on a site, I'll store that in:

src\delivery\APPCODE.Delivery.Web\Features\Images\ImageViewModel.cs

and that might be the only class in that file.

So, I'm typically combining multiple types in a single file when there is a strong relationship between them and one of the types 'owns' the others.

[themarkschmidt]

Thanks for the detailed reply @seangwright . It "feels" like it breaks so many rules that are in my head (one file, one thing). But it does keep things simpler and still follows (one file, one "concept"). They are all heavily related objects, and typically if one thing changes, then a few of them may change. Which... still follows the rule. It does feel cleaner (not 10 files all over the place, when you make "one change" and have to touch all of them). And, at the end of the day, as soon as something else is using it, you can easily refactor/extract. I'll have to give it a try. Thanks agian.

[Sean G. Wright]

I think you made a perfect TLDR of my post!