DataContracts с поведением

Question

Насколько это плохо? Я читал бесчисленное множество статей и никогда ранее не создавал абстрактные DataContracts с поведением, но кажется, что это решит проблему, которая у меня возникнет, и не позволит мне создавать фабрики повсюду, чтобы определить реализацию подкласса. У меня вопрос, буду ли я наказан, если решу добавить поведение в мои контракты с данными? Конечно, они не могут быть использованы и предназначены для выполнения определенных операций, специфичных для этого типа подкласса, прежде чем вызывать вызовы репозитория, и данные сохраняются. Я могу создать классы «Менеджер» для каждого подкласса, но это возвращает меня к фабрикам, и я пытаюсь использовать более полиморфный подход. Заранее спасибо.

Answer 1

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

В целом, я думаю, вам было бы лучше, если бы контракты на данные были контрактами на данные и не учитывали их поведение.

Answer 2

Почему вы не можете создать свой контракт данных (MyDataContract) классическим способом, просто поля данных, ничего больше, а затем извлечь из него свой класс поведения?

public class BehaviorialClass : MyDataContract
{
.....
}

Таким образом, у вас есть хорошее, четкое разделение проблем, ваш контракт с данными не "загрязнен" поведением, с которым он все равно не может справиться .....

Марк

Answer 3

Хорошим компромиссом для размещения поведения непосредственно в ваших DataContracts будет определение поведения как методов расширения либо в той же сборке, что и ваши контракты, либо в другой сборке целиком. Опционально, методы расширения могут быть размещены в отдельном пространстве имен из контрактов для дополнительной изоляции разделения данных и поведения.

Таким образом, ваши Контракты будут содержаться в чистоте, но в то же время потребители .NET ваших контрактов смогут легко импортировать дополнительные функции, относящиеся к этим DataContracts.

Answer 4

В какой-то момент вы захотите использовать MemberwiseClone и реализовать интерфейсы без ненужного промежуточного перевода данных (и, что еще хуже, без ненужного обслуживания). Методы расширения предназначены для случаев, когда вы буквально не имеете никакого контроля над определением объекта, но все еще нуждаетесь в объектно-ориентированной беглости; они добавляют занятую работу в любой другой ситуации и разбрасывают определения классов хуже, чем C / C ++. Воспользуйтесь «тенденциями» и сделайте то, что вам подходит, вы можете просто обнаружить шаблон, который меняет всю игру (например, AsyncEnumerator Джеффри Рихтера).