Как мне структурировать решение для Win-форм, управляемых данными?

Question

Я пишу приложение для Windows Forms, которое растет и становится все более обширным.

Изначально я думал, что лучшим проектом будет отдельный проект для графических компонентов и один для бизнес-логики, а другой - для доступа к данным.

Когда приложение становится больше, я начинаю думать, что более модульный подход будет чище ... например, проект, содержащий пользовательские элементы управления, бизнес-логику и доступ к данным для каждой «категории» данных.

Например ... Объекты DAL, относящиеся к Продуктам, вместе со связанными бизнес-объектами и пользовательскими элементами управления в одном проекте.Это должно привести к большему количеству проектов внутри решения, каждый из которых является самодостаточным.

Однако это может вызвать больше сложностей, поскольку данные часто связаны (таблица продуктов связана с таблицей поставщиков и заказами).таблица и список деталей, таблица и т. д.) Поэтому было бы трудно полностью абстрагировать каждую категорию.

В Интернете существуют сотни статей по архитектуре программного обеспечения, но не так много, которые помогут вам перевести эту архитектуру в решения, проекты и код.

Может ли кто-нибудь указать мне правильное направление?

Answer 1

Я бы держал пользовательский интерфейс, данные и бизнес-уровни в отдельных проектах.Это существенно снижает вероятность жесткой связи - например, если слой данных напрямую используется кодом пользовательского интерфейса и т. Д. Теперь, если вы хотите разделить это по вертикали, вы можете сделать это так же, как, например, у продуктов будет три проекта UI, Business & Dal искоро.Здесь может быть несколько соображений:

1. Почему вы разделяете вертикально - вы видите возможное независимое повторное использование?Если нет, то избегайте деления.
2. Если вам нужно разделить, то вы можете выбрать разделить, скажем, только пользовательский интерфейс, с точки зрения управления, потому что он может иметь много кода
3. Или вы можете разделить все слои, но с грубым зерном.Например, продукты, а также его дети вместе.

Что касается ссылок на разные категории, их нельзя избежать, но они должны быть выполнены посредством хорошо документированного и разработанного контракта.Например, пользовательский интерфейс Orders может вызвать Products BL для получения списка продуктов (обратите внимание, что этот же метод будет использоваться многими другими компонентами пользовательского интерфейса для аналогичной функциональности).

Answer 2

VinayC на это, вот некоторые дополнения, которые дополняют его ответ (слишком сложно в комментарии).

• Абстрагируйте все данные доступа за интерфейсами, так что вы можете поменять различные ии у вас не будет так много зависимостей, встроенных в остальную часть приложения.
• При разработке этих интерфейсов вы сможете применить некоторые из ваших «вертикальных» взглядов.См. Принцип разделения интерфейса и Принцип стабильных абстракций в качестве начала.
• Я бы сделал отдельную сборку (и проект) для каждого слоя, плюс "Общий""сборка для констант и т. д. Держите это как можно свободным от зависимостей.
• Там, где я использовал этот подход, я иногда помещал свои POCO в папку в общей сборке, чтобы их можно было легко перезаписатьиспользуемый.Интерфейсы, которые я использую для разделения BL и DAL, используют их, и я иногда использую их также между другими уровнями.
• Рассмотрите возможность использования атрибутов;они могут предоставить вам действительно полезную точку расширения.
• Поместите часто используемые элементы управления в библиотеки элементов управления для простого повторного использования.
• Не пытайтесь отделить части модели / данных предметной областимодель (например, заказ и детали), которые тесно связаны друг с другом в деловом смысле.