Как вы генерируете класс для LINQ to SQL? - PullRequest
Новая
       45

Как вы генерируете класс для LINQ to SQL?

3 голосов
/ 13 июля 2011

Я использую linq to sql для моего проекта MVC 3.Существует несколько способов создания файлов модальных классов домена.

  1. sqlmetal
  2. Object Relational Designer
  3. код руки

Я всегда рукойкод этих файлов классов модели.потому что файлы, сгенерированные sqlmetal или дизайнером, грязные.Каково твое мнение?Какой лучший способ сделать это.

РЕДАКТИРОВАТЬ:

Я использую MVC 3, а не 2. Может быть, я ошибаюсь, но это, как я проверяю.В любом случае я собираюсь написать все эти файлы классов, так какой смысл использовать инструменты для их генерации ??? 

public class User
{ 
    [Required]
    public string Password { get; set; } 
    [Required, Compare("Password")] 
    public string ComparePassword { get; set; } 
}

Ответы [ 2 ]

4 голосов
/ 13 июля 2011

У нас есть сотни таблиц в нескольких базах данных (один сервер). Мы занимаемся разработкой таблиц, перетаскивая таблицы в разные файлы дизайнеров DBML, каждый в разных папках, представляющих разные пространства имен в каждом проекте. Файлы конструктора помечены как не подлежащие компиляции, и мы используем специально созданный шаблон T4, который генерирует наш код путем чтения из любых файлов DBML в проекте. Это позволяет нам полностью контролировать сгенерированный код, поэтому мы можем реализовать такие вещи, как реализация интерфейса (IAuditable - один из примеров, где у нас есть CreatedBy, CreatedDate, ModifiedBy, ModifiedDate). Таким же образом мы также можем поместить System.ComponentModel.DataAnnotations в наши объекты Linqed, не прибегая к Классам друзей . У нас есть второй шаблон T4, который отвечает за обновление DBML из базы данных, поэтому мы можем убедиться, что таблицы имеют префикс из 3 частей (db.schema.tbl), и поэтому нам не нужно удалять и повторно добавлять в дизайнер. XML просто изменяется на основе чтения схемы БД и обновления DBML. Мы также создаем объект репозитория / менеджера для каждого POCO, который имеет несколько общих операций запроса, таких как GetByID (), а также обрабатывает фиксации и ведение журнала аудита. Эти менеджеры расширяются за счет всех пользовательских запросов, которые вам нужно написать для каждой таблицы, и им принадлежит DataContext. Этот дизайн иногда называют "Мама-может-я?" подход, при котором объект, привязанный к таблице, должен попросить своего менеджера сделать все для него.

Я обнаружил, что это очень универсальный и удобный способ работы с L2S, и это сделало нашу внутреннюю разработку простой, чтобы мы могли сосредоточиться на пользовательском опыте. Единственным недостатком является то, что если мы делаем ассоциации через пространства имен, вы должны вручную добавить их в частичный класс, потому что в противном случае вам пришлось бы добавить эту внешнюю таблицу в другой DBML, чтобы нарисовать ассоциацию. На самом деле это не так уж и плохо, поскольку заставляет нас задуматься о специфике наших пространств имен и сократить лишние. Использование T4 таким способом является отличным способом для разработки DRY (не повторяйте себя). Определение таблицы - это единственное место, где вам нужно изменить структуру, и все это распространяется. Валидация идет в одном месте, POCO. Запросы идут в одном месте, менеджер. Если вы хотите сделать что-то подобное, вот хорошее место, чтобы начать .

0 голосов
/ 13 июля 2011

Даже если классы, сгенерированные Дизайнером, грязные, какое это имеет значение для вас?

Полагаю, совершенно не нужно открывать один из файлов проекта.

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

Когда я использую L2S, я просто использую конструктор.

...