Дизайн-макет / Шаблоны

Question

Я все еще довольно новичок в C # и пытаюсь найти наилучший способ структурировать новую программу. Вот что я хочу сделать, и я хотел бы поделиться своей идеей.

• Уровень представления
• Бизнес-уровень (отдельная библиотека классов)
• Уровень данных (отдельная библиотека классов)
• Слой модели (отдельная библиотека классов)

Я борюсь с тем, чтобы все классы на уровне данных и бизнес-уровне наследовали типы, определенные в уровне модели. Таким образом, я могу расширить типы по мере необходимости в моем бизнес-уровне с помощью любых новых свойств, которые я считаю нужными. Я не могу использовать все свойства типа Model в моем классе Business Layer, но разве это действительно важно? Если это не достаточно ясно, я могу попытаться собрать пример.

Answer 1

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

Model/Data Layer:
    Customer
    Order

Business Layer:
    MyCustomer : Customer
    MyOrder : Order

против

Model/Data Layer:
    Customer
    Order

Business Layer:
    MyCustomer (encapsulates Data.Customer)
    MyOrder (encapsulates Data.Order)

При прохождении первого маршрута (наследования) есть две основные проблемы:

1. Когда вы изменяете базовый класс (данные / модель), вы вынуждены менять бизнес-класс.
2. Получение объектных отношений затруднительно и, как правило, требует неполиморфного подхода.То есть, если модель или слой данных предоставляет коллекцию Order s для объекта Customer, трудно и "грязно" заставить ваш класс MyCustomer предоставить коллекцию объектов MyOrder.

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

Судя по вашему имени, я предполагаю, что вы хотите написать приложение WPF.Если это так, посмотрите шаблон проектирования Model-View-ViewModel (MVVM) .

Answer 2

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

Что касается оставшихся частей вашего вопроса, я бы сослался на то, что я узнал от Мартина Фаулера, поскольку я не могу сказать лучше, чем он, и если я скажу, я просто повторяю за ним:1004 *http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/

Answer 3

Я думаю, что пример был бы хорошим - я не думаю, что вы предлагаете: обязательно плохо, но это зависит от того, чего вы пытаетесь достичь.

Почему вы наследуете от классов на уровне модели? Каков интерфейс и назначение определенных классов модели, и каково назначение классов бизнес-логики, которые наследуются от классов вашей модели?

Действительно ли наследование имеет смысл?

Будет ли наследование нарушать принцип замещения Лискова?

EDIT:

wpfwannabe, я бы с осторожностью использовал наследование только потому, что это, кажется, самый простой вариант. Я специально упомянул принцип замещения Лискова, потому что он имеет дело с определением, когда наследование действительно.

Кроме того, вы также можете взглянуть на принципы разработки SOLID для разработки ОО (включая принцип подстановки Лискова):

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)