2014-09-07 7 views
0

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

public void doStuffA(int a, string b, string c, bool d) 
{ 
    var params = ? 
    if (validateInput(params)) 
    { 
     // do stuff 
    } 
} 

public void doStuffB(string x, string y, int z) 
{ 
    var params = ? 
    if (validateInput(params)) 
    { 
     // do stuff 
    } 
} 

public bool validateInput(? params) 
{ 
    // do validation 
} 
+2

Я не рекомендую это. Вы потеряете возможность проверки вашей проверки параметров посредством статического анализа. – Dai

+0

Прежде всего: вы должны проверить аргументы, а не параметры. Сказав это, я согласен с Даем выше. Кроме того, если ваши классы придерживаются принципа единой ответственности, они, вероятно, не будут настолько большими, чтобы их методы могли извлечь выгоду из проверки общих аргументов. Не говоря уже о том, что «вы, скорее всего, будете программировать себя против стены и сделать рефакторинг вашего кода практически невозможным. –

+1

пожалуйста, просим пожалуйста. Не делай этого. Вы можете создать некоторые проверки по умолчанию в методах, которые вы можете вызвать, но вы не хотите иметь один метод, который проверяет все остальные.Неправильно переносить эту ответственность. –

ответ

1

Вы должны оформить в Enterprise Library Validation Application block. Он поддерживает проверку кода, атрибута и конфигурации.

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

[StringLengthValidator(0, 20)] 
public string CustomerName; 

В дополнение к использованию встроенного attributest проверки также довольно легко реализовать свои собственные валидаторы.

0

Ваш вопрос является правильным.

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

Я согласен, что это не ответственность бизнес-объектов, даже если люди, которые комментируют этот пост, продолжают выступать за разделение проблем.

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

В этом случае рассмотрите возможность использования Aspect Oriented Programming в качестве метода решения этой проблемы.

Я считаю, что PostSharp может предоставить вам это решение, если вы используете .NET или WinRT. В частности, вы хотите использовать аспекты OnMethodBoundary, которые предоставляет этот инструмент. При применении этого атрибута к вашим методам или классам вы предоставляете вашему приложению возможность выполнять логику до того, как метод будет выполнен и/или после выполнения метода.

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

Смежные вопросы