Помощь в структурировании модели домена Telerik OpenAccess - PullRequest
Новая
       25

Помощь в структурировании модели домена Telerik OpenAccess

0 голосов
/ 02 марта 2011

Моя компания собирается начать новый проект с использованием Telerik OpenAccess ORM. Это новый продукт для нас, и в первый раз мы будем использовать ORM для проекта вместо подхода, основанного на наборе данных. В настоящее время у нас есть некоторые разногласия относительно лучшего способа структурировать наш слой данных. В частности, если у нас есть один файл .rlinq и модель домена для проекта, или мы должны иметь для каждого экрана / модуля файлы .rlinq, которые содержат только таблицы и столбцы из таблиц, необходимые для этого конкретного экрана / модуля. Чтобы проиллюстрировать последнее:

Скажем, у нас есть таблица Person, с полями для имени, фамилии, ssn, даты рождения, пола и семейного положения. На экране личной информации нам нужны все эти поля, поэтому мы включаем всю таблицу в модель предметной области в этот файл .rlinq. На другом экране (с отдельным файлом .rlinq) нам нужны только фамилия человека и ssn, поэтому объект Person в этом файле .rlinq содержит только фамилию и ssn.

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

Если это имеет значение, мы создаем приложение для интрасети на основе Windows Forms, и уровень данных будет находиться за службами WCF, а база данных будет иметь около 100 таблиц.

Заранее благодарю за помощь!

1 Ответ

1 голос
/ 23 июня 2011

В общем случае лучше всего иметь твердотельную модель домена в одном файле RLINQ.Затем вы можете обрабатывать проблемы с экраном, проецируя запросы в ScreenModels / DTO по мере необходимости.

Например

Допустим, у вас есть объект person с несколькими свойствами, однако на определенном экране вы хотите только вернуть имя и фамилию.

   var myUserDto = context.People
                          .First()
                          .Select( p => new UserDto { FirstName= p.FirstName, 
                                                      LastName=p.LastName });

В этом случае OpenAccess достаточно умен, чтобы запрашивать только имя / фамилию.Теперь, когда экран завершает работу, требуя другого свойства, доступного в объекте person, вам нужно только обновить запрос dto и LINQ.

Кроме того, если вы планируете использовать Мастер обслуживания данных OpenAccessобеспечивает, это создает сервис для OpenAccessContext.Таким образом, если у вас есть RLINQ для каждой сущности, у вас будет служба для каждой сущности, которую было бы болезненно поддерживать на клиенте, если не сказать больше.Если вы прокрутите слой службы вручную, вы, очевидно, будете иметь немного больше контроля, но вам все равно нужно будет постоянно помнить, какой OpenAccessContext обрабатывает каждый объект домена.

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

Надеюсь, это поможет!:)

...