Соответствующая модель для данного сценария

Question

Я занимаюсь разработкой .NET обертки над службой, где следующие объекты присутствуют:

• Коренного свойство Имя, файлы, папки, товары
• Предмет свойство Имя, методы Создание, переименование, удаление
• Файл свойства Name, методы создания, переименование, удаление
• Папка свойства Name, файлы, папки, методы создания, переименования, удаления

Как вы можете видеть, Root entitiy (что синглтон) может содержать несколько файлов, папок и элементов. Элементы могут храниться только Root, они не могут присутствовать в любой папке. С другой стороны, файлы и папки можно использовать как для корневых, так и для папок.

Я пытаюсь выяснить, что было бы лучшим способом проецировать этот сценарий в код.

Service.Root будет единственным объектом, возможно, не так много.

Service.Root.Files & Service.Root.Folders - должен ли я создавать пользовательские коллекции классов файлов и папок для этой цели? И если да, должен ли я создавать новые экземпляры классов файлов и папок только через методы в этих коллекциях? Или я должен разрешить разработчику создавать файл/папку без явной ссылки на «Сервис», создав для этого публичный конструктор? Наверное, нет? Потому что, например, переименование файлов вызывает методы в службе, которая работает с сетью. Так должен ли каждый экземпляр File, Item & Папка иметь ссылку на Сервис?

Этот вопрос, вероятно, очень грязный, но я не знаю, как это объяснить, извините. Как правило, я спрашиваю, стоит ли создавать пользовательскую коллекцию типов файлов/предметов/папок или лучше отображать общие коллекции. Кроме того, если эти открытые коллекции должны быть только для чтения и создавать новые файлы, вызывая Service.CreateNewFile() вместо Service.Folders [0] .Add (Новый файл()), если вы знаете, что я имею в виду.

Благодарим за любые вопросы и/или хорошие ссылки, обсуждая такие шаблоны разработки.

Аарон

Answer 1

Вы могли бы использовать немного и для достижения своей цели. Предоставление коллекций как свойств даст пользователю самый гибкий и знакомый интерфейс. Однако, принимая больший контроль над коллекциями, подвергая их свойствам только для чтения, а затем предоставляя методы для добавления, удаления и т. Д., Вы получите больше, чем у дизайнера классов. Это может привести к меньшему количеству проблем, поскольку доступ к коллекциям происходит только через ограниченный интерфейс. Таким образом, ваш компромисс является одним из элементов гибкости и контроля. Оба подхода будут работать.