Наследовать или не наследовать? Некоторые профессиональные мнения хотели

Question

Я разрабатываю веб-приложение C# ASP.Net, которое использует множество общих функций и правильный способ справиться с этим, кажется, через наследование. Я планирую создать базовый класс (Person) и наследовать его в других классах, таких как Employee and Vendor, а затем, в свою очередь, наследовать Employee with Manager и т. Д. Таким образом, мне не нужно определять общие свойства, такие как FirstName, LastName, PhoneNumber и т. Д. На каждом из них.

Вторая часть вопросов такова: если я использую наследование и использую объекты Entity Framework CodeFirst, они поймут наследование? Как данные будут храниться в таблицах? Будет ли каждая таблица иметь столбец FirstName и LastName, или EF достаточно умный, чтобы сделать их общей таблицей?

Я действительно надеюсь, что кто-то, кто является REAL объектно-ориентированным программистом, может помочь мне разобраться в этом. Я получил много информации, и мне нужен кто-то с опытом работы над проектами EF, чтобы дать мне несколько советов. Я правильно понимаю право наследования? Если нет, что я ошибаюсь? Любая помощь приветствуется.

Спасибо,

Bert

Answer 1

Это не простой вопрос, но в большинстве случаев это лучше выбрать композицию вместо наследования. Вы не должны выводить банкомат из калькулятора только потому, что калькулятор имеет свойства отображения и клавиатуры. Это нелепо.
Но иногда наследование имеет смысл. Спросите себя, должны ли эти классы иметь «отношения»? Поскольку я вижу вашу задачу, лучше сделать Vendor and Employee независимыми классами, у обоих есть свойство Person. И получить Менеджер от Employee.
Тем не менее, храните глубину наследования как можно меньше. Глубокие иерархии - это боль для отладки и понимания, особенно если есть много переопределений методов. Подробнее о теме см. На Chad Myers blogpost.

Answer 2

Первая 1: Звучит хорошо. Но убедитесь, что задана «есть». Не выводите человека из адреса только для включения свойств, специфичных для адреса. Используйте типы сложных EF для такого повторного использования.

Одна проблема, которая приходит мне на ум: Вы уверены, что Vendor является подтипом Person?

Подробнее об этом: убедитесь, что вы остаетесь в пределах «одного домена» с вашим наследованием. Поскольку Vinny опубликовал в другом возможном ответе, если один и тот же Человек может быть Менеджером и CustomerContact и оба наследуют от Лица, вы сталкиваетесь с проблемой. Однако, если менеджеры и контакты с клиентами находятся не в одном домене, вероятно, лучше добавить данные человека дважды - возможно, тот же человек хочет иметь ваши разные контактные данные в качестве менеджера, а не как контакт с клиентом.

Часть 2: Вы можете выбрать то, что генерирует EF: http://www.entityframeworktutorial.net/code-first/inheritance-strategy-in-code-first.aspx

Answer 3

С объектно-ориентированной точки зрения проблема с этим подходом заключается в том, что человек становится менеджером, сотрудником, продавцом или всеми из них. На некоторых латинских языках мы должны формировать глагол (ser/estar). Первое относится к природе существа, а затем к государству. Лучше использовать isA для наследования, когда ссылается на природу существа, а не на его состояние. В вашем случае я бы рекомендовал использовать роли. Человек имеет много ролей. Менеджер - Роль (Менеджер наследует от Роли), Сотрудник - Роль и т. Д. Таким образом, вы можете повторно использовать свои персональные атрибуты, и вы можете добавлять и удалять роли человека.