Использование нескольких внешних ключей для одной и той же таблицы в LINQ

Question

У меня есть таблица Users и таблица Items

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

ModifiedBy Создано AssignedTo

, которые имеют целое число userId. База данных настроена так, чтобы эти ключи возвращались в таблицу Users.

При использовании LINQToSQL отношения, которые автоматически строятся из dbml, в итоге дают мне такие имена, как User, User1 и User2

например. myItem.User1.Name или myItem.User2.Name

Очевидно, что это не очень читабельно, и я бы хотел, чтобы это было похоже на

myItem.CreatedByUser.Name или myItem.ModifiedByUser.Name и т. Д.

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

Есть ли способ обойти это?

Answer 1

Немного поздно, но вы можете сделать это, выбрав отношение в модели linq и перейдя в свойства и обновив имя родительского свойства.

Answer 2

Я просто добавляю небольшой частичный класс для расширения объекта с подходящими именованными свойствами, пример ниже:

namespace Database.TableModels {
    partial class WTSR_Induction {
        public EmailTemplate ConfirmationEmailTemplate {
            get { return EmailTemplate1; }
        }
        public EmailTemplate InviteEmailTemplate {
            get { return EmailTemplate; }
        }
    }
}

В этом примере таблица WTSR_Inductions имеет две ссылки на таблицу EmailTemplates, следовательно, свойства EmailTemplate и EmailTemplate1.

Answer 3

Простой ответ: Нет.

Кто-то предложил идею создания частичных классов ассоциации, в которых определены имена свойств, но это также не сработает: Переименование свойств сущностей SQL LINQ 2 через частичные классы .

Ваш выбор - либо потратить немного времени на изучение «закулисных» операций LINQ-to-SQL, чтобы вы могли вручную внести необходимые изменения, либо просто изменить имена свойств в окне «Свойства». Лично я просто удаляю / redrag / rename, потому что неправильная установка свойства - трудная задача для отладки, потому что генерируемые исключения не дают вам никакого представления о том, что вызвало это. Я даже зашел так далеко, что создал библиотеку модульных тестов, которая берет каждый объект MetaTable в модели и проверяет количество полей, содержимое ServerDataType каждого поля, количество ассоциаций, имена каждой ассоциации и имена каждого конца Ассоциация. Каждые несколько изменений я запускаю модульные тесты, чтобы убедиться, что модель не повреждена.

Answer 4

Во-первых, нет ... имена создаются на основе второй таблицы в связи.

Но вы должны знать, что вам не нужно «обновлять» (то есть удалить таблицу в DBML, а затем снова перетащить ее).

Для проекта, над которым я работаю, у нас есть более 200 таблиц ... около 50 из которых мы настроили вручную после перетаскивания их из базы данных. Мы никогда не удаляем и не перетаскиваем таблицы, так как после автоматической генерации было так много изменений.

Answer 5

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

Я только что столкнулся с этой проблемой сам, и я собираюсь реализовать свое собственное предложение.

РЕДАКТИРОВАТЬ: Это представляется актуальным: Многочисленные внешние ключи SQLMetal, указывающие на одну проблему таблицы

Answer 6

Вы можете использовать linq to sql без dbml , это может быть дополнительной работой заранее, но с точки зрения изменения имени столбца таблицы это может быть проще, чем изменения в dbml, как вы описали.