Получение наборов строк на уровне представления
Мы работаем над информационной системой больницы, которая написана на C# и использует NHibernate для сопоставления объектов с базой данных. Шаблон MVC используется для отделения бизнес-логики от пользовательского интерфейса. Вот в чем проблема,
Как получить в пользовательский интерфейс набор строк различного размера?
Например, объект Contact имеет свойство с именем City, которое содержит информацию о том, какой город проживает. В стране, для которой написано приложение, более 80 городов. Как можно было записать эти города в поле со списком? (или сетка данных, таблицы, ...) В этом примере номер города фиксирован. Долго добавлять еще один город нет необходимости. (Если список городов изменится, перекомпиляция не проблема)
Например, объект Contact имеет другое свойство с именем FooBar, которое будет содержать 1000 различных строковых значений, и эти значения будут выбраны из поля со списком для этого свойства. И этот набор при желании можно расширить. Как загрузить эти значения в поле со списком? (Если список строк статически записан в объект поля со списком, перекомпиляция является проблемой)
У меня есть разные решения, как показано ниже
- Все строковые значения статически записываются в поле со списком в коде или конструкторе
- Получить значения из файла ресурсов
- Запишите эти значения в файл XML (на самом деле то же, что и выше, но не нужно перекомпилировать)
- Создайте объект
Cityи получите значения в список из таблицыCITYс помощью NHibernate - Создайте класс с именем
StringHolder, который имеет свойстваTypeиValue. Все строковые значения (включаяCityиFooBar) будут записаны только в одну таблицу с именемSTRINGHOLDER. И получите эти значения с помощью ключа типа «CITY» или «FOOBAR» с помощью NHibernate.
Какой бы вы выбрали? Или вы могли бы предложить мне другой?
Спасибо всем
Ответы 3
Я бы проголосовал за решение №4. Так я всегда поступал в подобных ситуациях. Это просто кажется более чистым решением.
Если я использую наследование, будет много пустых классов, таких как Contact, FooBar и т. д. Как вы думаете?
Если City просто будет держать строку и никогда не будет использоваться для чего-либо еще, тогда Table может быть излишним. Но много раз, когда код находится в производстве, вы можете найти для него новые применения / потребности. Я лично использую таблицы поиска / объекты домена для таких объектов, как город (государства, страны).
Таких наборов струн будет очень много. Решение №4 займет слишком много времени для слишком большого количества сущностей. Думаю, мы выберем №3 и посмотрим, сработает он или нет. Но, как я уже сказал, строковые значения (вместо целочисленных ключей к этим значениям) займут слишком много места в базе данных с # 3. Еще раз спасибо
Если места на самом деле будут использоваться для чего-либо, внесите их в базу данных. Если данные «на самом деле не используются», но для улучшения пользовательского интерфейса предоставляется поиск по городам, то вариант с файлом XML - тоже неплохой вариант.
Под использованным я имею в виду такие вещи, как перечислить всех сотрудников в Нью-Йорке и тому подобное. Если это «мертвые данные», просто для отображения, выберите решения, которые потребуют наименьшего объема работы и наименьшего риска - что может быть вариантом файла.
Например, каждый контакт, добавленный в базу данных, имеет поля City и FooBar, которые появляются из полей со списком. Так что это не так уж и плохо :) В некоторых строковых наборах некоторые строковые значения содержат более 100 символов. Для каждого контакта добавляется строка, и все строки занимают 100 символов только для одного поля.
Если я сделаю это так, возникнет проблема "нормализации". Большинство строк в таблице будут иметь одинаковое значение в поле FOOBAR. Если я сделаю классы для каждого набора строковых значений, дизайн домена будет беспорядочным :) У обоих есть свои преимущества и недостатки. Что ты говоришь?
Я придерживаюсь того, что сказал. В идеале ваша модель предметной области не должна заботиться о том, как выглядит база данных, кстати, классы предметной области должны выглядеть так, как вы хотите, чтобы ваш код работал. Но если вы храните города в db, я бы нормализовал и получил отдельную таблицу городов с идентификаторами.
Как вы относитесь к использованию List <string> для списка городов? Загрузите этот список строк в свой DAL или BL, а затем передайте его в пользовательский интерфейс.
То же решение должно подходить и для значений FooBar.
Если у вас есть идентификаторы, связанные с City или FooBar, скажем, NY, а его числовой идентификатор в БД равен 1, тогда вы можете использовать KeyValuePair <TKey, TValue>. С помощью дженериков вы можете диктовать, какие данные должны входить в этот KeyValuePair. Название города или строковое значение FooBar может быть ключом, а числовой идентификатор - значением.
Всего 2 цента.
Но Сити будет держать только веревочку. Как вы думаете, подходит ли это для модели предметной области? публичный класс City {частная строка _name; общедоступная строка Имя {get {return _name;} set {_name = value;}}} Если я не использую наследование, таких классов будет много.