Структурные изменения в приложении Asp.Net MVC при поддержке sprocs - PullRequest
0 голосов
/ 25 января 2012

Здравствуйте, разработчики.

Прежде всего, я заранее прошу прощения за стену текста, которая следует, но после дня, когда я схожу с ума по этому вопросу, мне нужно позвать на помощь.

IЯ наткнулся на проблему, которую не могу решить.Я постараюсь описать сценарий как можно лучше.

Задача на руку: в существующем приложении Asp.Net Mvc создайте таблицу поиска для целочисленного поля и используйте текстовое значение из поискав режиме редактирования.При сохранении мы должны сначала проверить, имеет ли поиск уже соответствующее текстовое значение для того же Root идентификатора.Если есть, используйте это.В противном случае создайте его и затем используйте.

Структура:

Модель данных - это граф объектов, в котором у нас есть корневой объект, коллекция дочерних объектов уровня A и каждый уровень.Дочерний объект имеет коллекцию дочерних объектов уровня B, что-то вроде этого:

  • Root (с полями)
    • Дочерний уровень A (с полями) xn
      • Дочерний уровень B (с полями) xn

Поле, которое мы должны обработать, находится на объектах LevelB.

Существуетодно представление Mvc, которое обрабатывает все данные.Для объектов коллекции все поля именуются как levelA1levelB1MyField, levelA1levelB2MyField и т. Д., Поэтому каждое поле имеет уникальное имя во время публикации.Когда сообщение происходит, все значения читаются через параметр formCollection, который имеет в среднем 120/130 ключей.Ключи изолируются путем их разбиения и зацикливания на числовой части имен, значения считываются и анализируются для ожидаемых типов и присваиваются графу объектов.

Часть данных, поддерживающая граф объектов, - это все хранимые процедуры.и все сопоставление (как объект sproc, так и sproc объект) написано от руки.Для части чтения есть одна хранимая процедура, которая получает несколько наборов данных, а вызывающий ее метод читает наборы данных и создает граф объектов.

Для сохранения существует несколько sprocs, в основном «CreateRoot» и"UpdateRoot".Когда код должен выполнять такие задачи, происходит следующее:

  • Для сценария создания вызывается «CreateRoot», затем в цикле вызываются sprocs «CreateLevelA» и «CreateLevelB» для каждого элемента вграфик;
  • Для сценария обновления вызывается «UpdateRoot», который внутренне удаляет все элементы «LevelA» и «LevelB», затем код воссоздает их, вызывая вышеупомянутых sprocs в цикле.

Последняя полезная информация заключается в том, что «граф бизнес-объектов» используется непосредственно в качестве модели представления в представлении, а не отображается в простой «дружественной к HTML» модели представления.Это может быть то, что доставляет мне больше всего хлопот.

Так что теперь текстовое поле в представлении обрабатывает поле "целое число".Это поле должно теперь принимать строку.Поле на уровне B должно оставаться целым числом, только с таблицей поиска (с FK, конечно) и текстовым полем из поиска.

Подходы, которые я пробовал безуспешно:

  • Моей первой мыслью было изменить тип данных для свойства MyField с целого на строку на объекте, затем соответствующим образом изменить sprocs и обработать соединение на уровне sproc: у меня будет согласованный объект для моего представления,и sprocs для чтения / записи могут переводить из строки в целое число и наоборот, но я не могу этого сделать, потому что ключи объединения для получения целого числа при записи являются частью элемента Root (как я уже говорил в первых строках этоготекстовая стена), которую я не знаю в CreateLevelB sproc, и изменение всей цепочки вызовов для передачи этих параметров окажет огромное влияние на остальную часть приложения, поэтому ничего хорошего.
  • Моя следующая попытка состояла в том, чтобы держать вещи «как они есть» и вызывать некоторые «методы перевода»: при чтении передайте целое число в представление и там вызовите метод перевода, чтобы отобразить текстовое значение. При сохранении используйте опубликованный текст, чтобы получить целое число. Часть сохранения работала бы, у меня были бы все необходимые параметры, но для части чтения мне нужно было бы создать экземпляр «уровня доступа к данным» и вызвать его метод на уровне просмотра, и нет необходимости объяснять, почему Это очень плохой выбор, поэтому я тоже исключил это.

Теперь у меня нет вариантов (или идей в любом случае). Любые предложения по решению этой проблемы очень приветствуются, а также, если что-то недостаточно ясно, просто укажите на это, и я отредактирую свой пост с более точной информацией.

Спасибо.

1 Ответ

1 голос
/ 26 января 2012

Это не реальный ответ, но вы можете удалить все спроки и использовать средства обновления OR mapper. Это решит все проблемы с наслоениями. Вы просто обновляете данные так, как считаете нужным, и отправляете их в конце.

Полагаю, это также уберет вопросы о том, "использовать ли int или строку".

Редактировать: Прочитав ваш комментарий, я подумал о следующем: не реализовывать альтернативу 1. Вы скорее хотите пожертвовать качеством кода в представлении, чем в модели хранения данных. Последний является более важным и более централизованным.

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

Может быть, вы могли бы создать модель представления в вашем контроллере и выполнить переводы между DAL-моделью и моделью представления? Или этот шаблон не разрешен?

...