Объектно-ориентированный дизайн: Сохранение сложных объектов

Question

У меня есть сложная модель домена, построенная поверх устаревшей системы, на которой я построил большинство методов «get» - обычно просто передавая идентификаторы первичного ключа базы данных. Достаточно легко. Мне сейчас любопытно, как подойти к задаче создания новых объектов в базе данных и сохранения существующих с новыми данными, и я хочу, чтобы я покрывал все свои базы.

Основные объекты домена, соответствующие объектам в базе данных около 20-25 для всего проекта. Около 10 или около того необходимо будет сохранить (остальное только для поддержки данных и не нуждается в обновлении пользователем). Объекты, которые должны быть сохранены, имеют сложные зависимости. Объект A имеет список объектов B, который содержит объекты C, D и E, например, все они могут быть сохранены, когда исходный объект A есть.

Я хотел бы его построить, поэтому его легко использовать разработчиком пользовательского интерфейса, но также обеспечивает сохранение только достоверных данных (скажем, возможно, объект B не может сохранить, если объект C не находится в допустимом состоянии). Это заставляет меня уклоняться от того, чтобы позволить им создать объект с нуля и попытаться его сохранить. Я хочу следовать принципу, что объекты должны быть живыми только в правильном состоянии.

Другая альтернатива - использование методов «CreateNew» и «Save» для объектов службы, которые обрабатывают их, но список параметров для таких методов был бы вопиющим.

Я думаю о необходимости «CreateNew» и «Сохранить», чтобы принять что-то вроде объекта команды, который они могут создавать и передавать, чтобы они точно знали, какие данные необходимы и что они не могут контролировать. Я читал на command pattern, но мне не нужны никакие основные льготы, которые он предоставляет.

Какие соображения следует принимать при выборе подхода? Это C# 3.5, если это вообще влияет на него.

Answer 1

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

Метод может возвращать логическое значение, указывающее успешность операции. Не нужно бросать исключения, чтобы упростить разработку пользовательского интерфейса.

Затем выведите метод GetValidationErrors. Если AttemptSave возвращает false, разработчик пользовательского интерфейса должен вызвать этот метод для извлечения и отображения ошибок.

В качестве альтернативы вы можете добавить метод проверки Validate, который предварительно проверит иерархию объектов. Вы можете вернуть ошибки проверки с помощью GetValidationErrors. Затем будет выполнен вызов функции AttemptSave. Если это не удастся, вы можете вернуть ошибки с помощью GetOperationErrors.

Что-то в философии SQL. Либо ваш запрос был успешным, либо всегда, вы всегда можете посмотреть @@ ROWCOUNT, чтобы получить представление о том, выполнил ли запрос хотя бы часть задания.

Answer 2

Вы должны исследовать популярные объектно-реляционные структуры отображения для .NET. Многие люди справлялись с этой проблемой раньше, и некоторые из самых умных людей делились плодами своего труда с нами. У них множество функций, и самые популярные из них сильно тестируются.

Каждые несколько дней, кажется, кто-то новый запрашивает рекомендации .NET ORM, поэтому существует множество тем переполнения стека, которые помогут вам.Например:

• What are your favorite .NET Object Relational Mappers (ORM)?
• What ORM frameworks for .NET Do You Like Best?
• Which ORM for .net would you recommend?

(Если вы будете искать на 'ОРМ' и '.NET' вы превратитесь на много много больше матчей.)

В типичном использовании разработчик пользовательского интерфейса имеет дело только с высокоуровневыми родительскими объектами (называемыми «совокупными корнями» на языке Domain-Driven Design). Они используют ORM как Repository, и это гарантирует, что все операции в данном Сохранить объединены в разумные транзакции. (Вы все еще должны обеспечивать законность каждого бизнес-правил в ваших объектов домена.)

Вот упрощенный взгляд на то, что пользовательский интерфейс код будет выглядеть следующим образом:

// Given an IRepository implemented by your ORM, 
ICustomer customer = repository.Get(customerId); 

// ... do stuff to customer and its child objects ... 

repository.Save(customer);