Как создать платформу поверх CSLA? <- если в этом есть смысл

Question

Вот сценарий, я разрабатываю приложение, используя csla 3.8 / c # .net, приложение будет иметь разные модули. Это как ERP, он будет иметь бухгалтерский учет, ежедневный учет времени, набор персонала и т. д. в качестве модулей.

Теперь требуется проверить общие сущности для каждого модуля и построить из него «платформу» (<- так ее называет босс). Например, в DTR будет сущность «сотрудник», в Recruitment будет «Заявитель», поэтому одна общая сущность, которую вы можете извлечь из обоих, которую можно поместить в платформу, это «Персона». «Персона» будет содержать типичную информацию, такую ​​как имя, адрес, контактная информация и т. Д. </p>

Я знаю, это звучит как ООП 101. Дело в том, что я не знаю, как мне поступить. как бы мне хотелось, чтобы это было просто наследование, но требование состоит в том, чтобы создать какой-то API-интерфейс для использования модулями, использующими CSLA.

в csla вы правильно создаете смарт-объекты, наследуя от базовых классов csla, таких как businessListbase, readonlylistbase и т. Д. Верно? что, если, например, я создал класс «Заявитель» в бизнес-базе, у него теперь будут такие свойства, как спрос на зарплату, дата доступности и т. д. Теперь для личной информации мне понадобится «Человек» с «платформы» и он будет реализован в классе кандидата.

итак, у меня есть несколько вопросов:

1. как создать такую ​​платформу?
2. если такая платформа возможна, как она будет реализована на объектах каждого модуля? (я уже наследую от базовых классов csla)
3. если возможны случаи 1 и 2, имеет ли это преимущества при разработке и обслуживании приложения?

причина, по которой я спрашиваю # 3, заключается в том, что, как я это вижу, даже если мне удастся создать платформу для этого, мне нужно будет определить свойства объекта платформы на объектах моего модуля, чтобы проверка и все.

Answer 1

Вы правы относительно наследования от базовых классов.

1. Я бы начал с разработки вашей базовой сущности без учета каких-либо отношений. Затем я создал бы ваши классы, которые наследуются от вновь созданного объекта, и добавил дочерние свойства, которые извлекаются из базы данных (через отношение FK) из родительского объекта. Я также рекомендовал бы проверить наши шаблоны CSLA 3.8.2 . Они выпускаются как на VB.NET, так и на C # и значительно облегчат эту задачу.
2. Да, это возможно, просто следуйте инструкциям, изложенным в # 1.
3. Я не уверен в преимуществах или недостатках, но это должно быть легко поддерживать в будущем. Ваши производные классы могут добавлять правила поверх / иметь полный контроль над правилами базовых классов.

Спасибо Блейк Немийски (Автор шаблонов CodeSmith CSLA )

Answer 2

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

В конце концов, мое решение состояло в том, чтобы просто определить объекты, которые будут использоваться несколькими модулями, и отделить его в другом проекте, чтобы другие модули просто использовали этот проект, когда ему нужен объект от него.

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

Спасибо за ответ, Блейк. Кстати, мы действительно используем для этого кузнеца. спасибо за предложение еще. Ура!