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

Question

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

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

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

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

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

Information service patterns, Part 3: Data cleansing pattern

LINQ to SQL - Format a string before saving?

How to trim values using Linq to Sql?

Answer 1

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

Абсолютно.

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

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

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

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

Answer 2

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

Используйте классный метод расширения, в котором используется отражение (не начинайте с того, что я размышляю о том, что отражение медленное until you know how it works) или что-то, что нужно копать во всех свойствах 'string' (например) вашего графа объектов домена. Here is an example that uses this technique to adjust DateTime values - фиксированное смещение - обратите внимание на то, как он «смещает» все DateTime значения даже в коллекциях или других настраиваемых типах. В вашем случае компенсация будет вашей обрезкой. Это, безусловно, проще, чем добавление .Trim() на все шоу и их можно легко отделить.

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

Answer 3

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

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