Design Layout/Patterns

Question

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

• Presentation Layer
• Business Layer (отдельная библиотека классов)
• Уровень данных (Отдельная библиотека классов)
• Модель Layer (отдельная библиотека классов)

То, что я борюсь с это если это нормально, чтобы классы в слое данных и бизнес-слое наследовались от типов, которые я определяю в слое модели. Таким образом, я могу расширить типы по мере необходимости в своем бизнес-слое с любыми новыми свойствами, которые, по моему мнению, подходят. Я не могу использовать каждое свойство из типа 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. Получение объектных отношений затруднено и обычно требует неполиморфного подхода. I.E., если модель или слой данных предоставляет коллекцию Order s на объекте Customer, сложно и «kludgy» получить ваш класс MyCustomer, чтобы выставить коллекцию объектов MyOrder.

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

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

Answer 2

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

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

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

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

EDIT:

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

Кроме того, вы также можете посмотреть на «ТВЕРДЫХ» принципы проектирования для разработки ОО (который включает в себя принцип замещения Лисков в):

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

Answer 3

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

Что касается остальных частей вашего вопроса, я хотел бы сослаться на вас, что я узнал от Мартина Фаулера, как я не могу сказать лучше, чем он, и если я делаю, я просто повторять за ним:

http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/