Как проверить порядок параметров C#

В настоящее время я работаю над системой CQRS.Как проверить порядок параметров C#

Он использует команды и события, которые являются стандартной практикой. Команды и события - это только классы .NET, но эти классы часто содержат несколько идентификаторов в качестве свойств, и эти идентификаторы - это все гиды.

Это приводит к возникновению проблемы при построении классов. Существует большой, если не огромный риск того, что кто-то из команды вызовет конструктор с параметрами в неправильном порядке. Вы можете себе представить, как эта простая проблема будет разрушительной, то есть OrderId, назначенной CustomerId и наоборот.

Итак, я ищу идеи, как это решить.

У меня есть некоторые идеи.

Создайте отдельный тип для каждого Id. То есть замените guid большим количеством типов. Это очевидное решение OO. Но мне это не нравится по ряду причин.
Согласованное присвоение имен и Unittesting: Если мы всегда называем Id таким Id. Мы можем проверить, что список параметров в вызывающем и вызываемом абонентах одинаковый (или аналогичный). И игнорируйте случаи, когда мы просто используем Guid.NewGuid(). Однако тест не прост. Для параметров вызываемого метода довольно легко получить список параметров с помощью Reflection или Mono.Reflection. Для звонящего это другое дело. Например, переменные в методе могут быть оптимизированы. Поэтому для тестирования вызывающего абонента нам нужно сделать что-то другое, кроме отражения, например, по стилю.

В целом, я не продаюсь ни по одной идее, а хотел бы сделать что-то более простое или, возможно, готовое решение?

источник

2014-06-23 Jesper Niedermann

Использование дискретного типа является «самым безопасным» внутри системы типов, но это только толкает, когда значения могут случайно пересекаться или смешиваться до другого уровня. Согласованное присвоение имен хорошо, независимо от того, требуется ли правильное тестирование (для семантической проверки, например, для упорядочения поля с одинаковой типизацией). (Кроме того, использование другого типа/дискретного типа строго не связано с ООП.) – user2864740

Этот вопрос кажется не по теме, поскольку речь идет не о конкретной проблеме программирования, а будет лучше подходит для [programers.stackexchange.com ] (http://programmers.stackexchange.com/). –

Кроме того, я не уверен, что это действительно имеет отношение к CQRS.Это больше связано с передачей значений в качестве параметров конструктору или методу с более чем одним параметром того же типа. Ответы, безусловно, будут упрямиться и могут кардинально измениться. –

Отдельный тип для каждого идентификатора - хорошее решение, но мне оно тоже не нравится.

Вызов метода тестирования устройства - очень сложная проблема. Согласованное присвоение имен всегда хорошее.

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

EDIT: Если вы можете убедиться, что не будет заказа и клиента (например) с тем же идентификатором (я думаю, что с GUID безопасным допущением) вы можете проверить, что они существуют, и если кто-то где-то смешивается эти два значения всегда будут ошибки во время выполнения, поэтому ошибка будет легко замечена.

источник

2014-06-23 17:59:58 Novakov

Да, я согласен с вами в определенной степени. Но проблема существует даже при наличии только двух параметров. –

Это правда, но заменить мышление машиной невозможно (надеюсь, так;)). Я добавил еще одну идею, чтобы решить эту проблему. – Novakov

Ваше редактирование интересно, но мне также нужна инфраструктура AOP. Потому что я не могу просто проверить, что оба значения существуют, потому что они это делают - я должен проверить, что они соответствуют правильному свойству. Или, может, я не буду следовать за тобой правильно? В любом случае с AOP я мог бы ввести код, который проверял свойства, используя либо вашу, либо идею Питера Смита. Поэтому, возможно, AOP на самом деле является ответом ... –

Одна мысль заключалась бы в префиксе GUID (как строки) с идентификатором типа. Таким образом, псевдо-GUID для идентификатора клиента xxyy становится cust_xxyy, однако, поскольку C# сильно типы, я бы предложил класс и свойства как правильный способ сделать это.

источник

2014-06-23 18:01:09

Префикс - интересная идея, но я не вижу, насколько она жизнеспособна. Тогда мне нужно будет проверить guid/string во всех вызовах методов? Хорошо, если я, возможно, использовал структуру som AOP. Ваше последнее утверждение такое же, как и моя 1. идея. –

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

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

Как проверить порядок параметров C#

ответ

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