Должен ли метод Trim обычно использоваться на уровне доступа к данным или на уровне домена?

Question

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

В целом, я вижу, что многие разработчики практикуют защитное кодирование, обрезая почти все строки из базы данных, которые, возможно, были введены пользователем в какой-то момент. По моему мнению, лучше сделать такое форматирование до того, как данные сохранятся, так что это делается только один раз, и тогда данные могут быть в согласованном и надежном состоянии. К сожалению, это не тот случай, который приводит меня к следующему лучшему решению, использующему метод Trim .

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

Я полагаю, что это несколько философский вопрос, который может определить ответ, который я мог бы задать " Должен ли доменный уровень отвечать за защитное / принудительное форматирование данных? " Имеет ли смысл иметь установленный метод доступа для свойство PhoneNumber бизнес-объекта принимает неформатированную или отформатированную строку и затем пытается отформатировать ее по мере необходимости, или эта ответственность должна быть перенесена на уровни представления и доступа к данным, оставляя уровень домена более строгим в типе данных, которые он будет принимать? Я думаю, что это может быть более фундаментальный вопрос.

Обновление: Ниже приведено несколько ссылок, которыми я поделился с этой темой.

Шаблоны информационных услуг, Часть 3: Шаблон очистки данных

LINQ to SQL - отформатировать строку перед сохранением?

Как обрезать значения с помощью Linq to Sql?

Answer 1

Я бы предложил "очистить" данные на прикладном уровне. Причина, по которой вы хотите сделать это здесь (да, выше в стеке, как предложил Dev Art), заключается в том, что ваша модель домена должна «моделировать» домен как можно ближе. Что если в какой-то момент времени все данные будут «чистыми»? Что ж, тогда вы можете удалить вспомогательный метод, который выполняет «очистку». Проще удалить его с места выше в стеке приложений.

Используйте классный метод расширения, который использует отражение (не говорите мне, что отражение медленное , пока вы не узнаете, как оно работает ) или что-то еще, чтобы покопаться во всех свойствах 'string' (например) график вашего доменного объекта. Вот пример, который использует эту технику для настройки DateTime значений на фиксированное смещение - обратите внимание, как это «сместит» все значения DateTime даже глубоко в коллекциях или других пользовательских типах. В вашем случае смещение будет вашей отделкой. Это, безусловно, проще, чем добавить .Trim() во всем шоу, и его можно довольно легко развязать.

Помните, что неверные данные являются сквозной проблемой для вашего домена, и поэтому не должны напрямую с ним связываться (подумайте AOP ).

Answer 2

Данные должны быть очищены перед сохранением. Теперь, когда оно сохраняется, у вас есть нечистые данные, которые, вероятно, необходимо очистить в базе данных. Подумайте о поиске клиента по имени. Могу ли я найти «Джон», «Доу», если я сохранил «Джон», «Доу».

Очистка данных как можно ближе к интерфейсу позволяет получить гораздо более простой код. Защитный код может измениться с кода очистки на утверждения. (т.е. строка подтверждения = обрезанная (строка)). Чтобы достичь этого, вам нужно очистить базу данных, а также код пользовательского интерфейса.

Answer 3

лучше сделать такое форматирование до сохранения данных

Абсолютно.

Должен ли домен позднее отвечать за защитное / принудительное форматирование данных?

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

Вы можете попробовать самовосстановление. Прочитайте данные и обрежьте их где-нибудь перед отображением в диалоге. Как только пользователь сохраняет этот диалог, данные в базе данных становятся «фиксированными».

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