Могу ли я остановить конструктор dbml от добавления строки подключения в файл dbml?
У нас есть настраиваемая функция AppSettings.GetConnectionString(), которая всегда вызывается для определения строки подключения, которая должна использоваться. Как эта функция работает, не имеет значения для обсуждения. Достаточно сказать, что он возвращает строку подключения, и я должен ее использовать.
Я хочу, чтобы мой LINQ to SQL DataContext использовал это, поэтому я удалил всю информацию из строки данных из файла dbml и создал неполный класс со стандартным конструктором, подобным этому:
public partial class SampleDataContext
{
public SampleDataContext() : base(AppSettings.GetConnectionString()) { }
}
Это отлично работает, пока я не использую конструктор для перетаскивания таблицы в диаграмму. Акт перетаскивания таблицы на диаграмму сделает несколько нежелательных вещей:
- Будет создан файл настроек
- Будет создан файл app.config
- В моем файле dbml будет встроена строка подключения
Все это делается до того, как я даже сохраню файл!
Когда я сохраняю диаграмму, файл конструктора воссоздается, и он будет содержать свой собственный конструктор по умолчанию, который использует неправильную строку соединения. Конечно, это означает, что у моего DataContext теперь есть два конструктора по умолчанию, и я больше не могу их строить!
Я могу отменить все эти плохие вещи, но это раздражает. Мне нужно вручную удалить строку подключения и новые файлы после каждого изменения!
В любом случае я могу остановить конструктора от внесения этих изменений без запроса?
ИЗМЕНИТЬ
Требование использовать метод AppSettings.GetConnectionString() было наложено на меня довольно поздно в игре. Я использовал что-то очень похожее на то, что он порождает для меня. Существует довольно много мест, которые вызывают конструктор по умолчанию. Я знаю, что я мог бы изменить их все, чтобы создать контекст данных по-другому (используя другой конструктор, статический метод, factory, ect..). Такое изменение было бы лишь немного раздражающим, поскольку это нужно было бы сделать только один раз. Тем не менее, я чувствую, что это обходит реальную проблему. Файл dbml и файлы конфигурации будут содержать неверную, если не использовать, строку подключения, которая в лучшем случае может запутать других разработчиков.
Ответы
Ответ 1
В дизайнере для DBML вы можете щелкнуть правой кнопкой мыши по любому пробелу и нажать "Свойства" (не то же самое, что щелкнуть правой кнопкой мыши по файлу DBML и щелкнуть "Свойства" ).
Оттуда разверните опцию "Подключение". Установите "Настройки приложения" на "Ложно" и снимите настройку "Строка подключения". Эти настройки используются разработчиком для создания этого конструктора по умолчанию.
Оттуда вы можете использовать созданный по умолчанию конструктор, созданный вне файла designer.cs. К сожалению, вам придется повторять этот процесс каждый раз, когда вы добавляете новые конструкторы в конструктор. Это раздражает, и я чувствую вашу боль.
Ответ 2
Вы можете использовать что-то вроде SqlMetal для создания собственного файла конструктора DataContext, но вы правы - DataContext по умолчанию довольно сложно для взлома.
Другой вариант - получить ваш DataContext с помощью метода factory, чтобы вы могли скрыть, какой конструктор фактически используется. Еще лучше, если вы это сделаете с помощью инфраструктуры IoC, например, Castle Windsor. Тогда вы сможете делать такие вещи, как:
var context = container.Resolve<DataContext>();
Ответ 3
Это немного "взломанный", но вы можете добавить параметр к своему конструктору (неиспользуемому?), использовать этот конструктор повсюду, а созданный конструктором по умолчанию не вызовет никаких проблем.
