Как удобнее передавать большое количество параметров?

@Dark Byte · Регистрация: 23.10.2014

Студворк — интернет-сервис помощи студентам

В продолжение этой темы. Я пишу WCF сервис и у меня очень много функций с похожими аргументами. Т.е. какие то аргументы совпадают и по именам и по типам, а какие то нет. Причем в каждой функции прилично аргументов где то от 2х до 5. Плюс я вот все еще пишу его, поэтому иногда где то добавляются аргументы, иногда убираются. Поэтому мне не удобно каждый раз везде менять прототипы. Я пока что сделал просто общий класс в который сложил все аргументы и передаю параметром. Т.е. те которые не используются остаются null при вызове. Но это тоже не очень удобно выходит, хотя бы потому что поди вспомни в какой функции у тебя какие параметры передаешь. В общем нельзя ли как то более удобно это сделать? С грустью вспоминаю о C# 7.0, там можно было бы удобно очень кортежи заюзать... Но поскольку он пока не доступен...

@Usaga · 12.05.2016, 15:19

Dark Byte, по хорошему, повторяющиеся параметры можно и нужно упаковывать в DTO. Там, где используется всего 2 или 3 параметра, можно обойтись и без DTO. Не вижу в этом особой проблемы.

Есть вероятность, что у тебе нужно пересмотреть архитектуру своего сервиса и его контрактов.

Если есть желание творить лютый говнокод, то можно сделать упор на Tuple.

@Dark Byte · 12.05.2016, 15:35 **[ТС]**

Сообщение от Usaga

Dark Byte, по хорошему, повторяющиеся параметры можно и нужно упаковывать в DTO. Там, где используется всего 2 или 3 параметра, можно обойтись и без DTO. Не вижу в этом особой проблемы.

По вашей ссылке слишком мало инфы, а нормального описания этого паттерна найти не удается...

Сообщение от Usaga

Есть вероятность, что у тебе нужно пересмотреть архитектуру своего сервиса и его контрактов.

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

Сообщение от Usaga

Если есть желание творить лютый говнокод, то можно сделать упор на Tuple.

Вот то то и оно что говнокод будет еще хуже чем сейчас. В C# 7.0 у кортежей параметры именованные вот в чем фишка...

@insite2012 · 12.05.2016, 15:44

Сообщение от Dark Byte

очень кортежи заюзать...

Чем вам существующие не угодили?

Добавлено через 2 минуты
Dark Byte, либо свой тип с dynamic параметрами. Естественно, строгая типизация потеряется, но по другому уже никак, раз у вас количество и тип аргументов меняется.

@Dark Byte · 12.05.2016, 15:51 **[ТС]**

Сообщение от insite2012

Чем вам существующие не угодили?

Сообщение от Dark Byte

В C# 7.0 у кортежей параметры именованные вот в чем фишка...

Говнокод выйдет... Поди разберись Item1, Item2... Мне вообще кортежи в сейчасшнем виде не нравятся

Сообщение от insite2012

Dark Byte, либо свой тип с dynamic параметрами. Естественно, строгая типизация потеряется, но по другому уже никак, раз у вас количество и тип аргументов меняется.

Да уж. Я тоже об этом думал. Но во первых строгая типизация теряется это первый минус, а во вторых я не уверен умеет ли WCF с dynamic и анонимными типами работать?

Добавлено через 1 минуту
Еще вариант передавать словарь. Dictionary<string, object> Но это тоже приводить опять надо везде... Да и опять таки надо помнить где ты что передаешь.

@insite2012 · 12.05.2016, 16:03

Сообщение от Dark Byte

умеет ли WCF с dynamic и анонимными типами работать

На счет dynamic точно не скажу, а с анонимными точно не сможет.

@LeniumSoft · 12.05.2016, 16:30

Сообщение от insite2012

На счет dynamic точно не скажу

dynamic трактуется как IDictionary<string,object>

только понту от него. Тоже говнокод редкостный выйдет.

Сообщение от Dark Byte

По вашей ссылке слишком мало инфы, а нормального описания этого паттерна найти не удается...

Что там описывать? Вместо параметров в метод передаётся модель с параметрами.

Из:

C#
1
2
3
4
5
6
[ServiceContract]
    public interface IUserService
    {
        [OperationContract]
        Task<bool> CreateUser(string name, int age);
    }

получаем:

C#
1
2
3
4
5
6
7
8
9
10
11
12
[ServiceContract]
    public interface IUserService
    {
        [OperationContract]
        Task<bool> CreateUser(User user);
    }
    
    public class User
    {
        public string Name {get; set;}
        public int Age {get; set;}
    }

можно UserDto написать дабы соответствовать статье.

@Dark Byte · 12.05.2016, 16:44 **[ТС]**

Сообщение от LeniumSoft

Что там описывать? Вместо параметров в метод передаётся модель с параметрами.

Ну и чем это отличается от того что я описал? А минус такого подхода в написании кучи классов для каждого метода. А если у меня вообще в каждом методе будут совсем разные параметры? И функций штук 20? Что теперь 20 моделей для каждой писать?

@LeniumSoft · 12.05.2016, 16:51

Сообщение от Dark Byte

Что теперь 20 моделей для каждой писать?

Пиши. Ну или можно с dynamic или Tuple поговнокодить.
Если бы ты мне такой сервис развернул и сказал, что мне надо туда передать Tuple, я бы тебя из под земли вытащил => пристрелил => и обратно закопал

DTO придумали дабы не говнокодить, когда в метод надо передать больше четырёх параметров.

@insite2012 · 12.05.2016, 17:12

Dark Byte, два замечания.
1. Я как-то не совсем понимаю, как можно начинать писать программу (сервис), не имея хотя бы более-менее четких установок. К примеру, я вот планирую написать одну прогу, по взаимодействию с сервисом. Первое, что я продумываю - это модели, которые будут в программе. Потом методы для работы с этими моделями. И потом уже как все это отобразить. Но писать вот так, без четкого плана - это как-то странно.
2. Ну и далее, раз уж вы работаете с WCF. Определите одну модель, и в процессе написания меняйте в ней поля. Студия сама все сделает, вам надо будет только обновить ссылку на службу. Еще вариант - использовать известные типы, возможно вместе с реализацией IExtensibleDataObject (при добавлении ссылки на службу Студия сама реализует его в контрактах данных на стороне клиента).
В общем, инструментов вполне достаточно. Пробуйте, используйте.

@Dark Byte · 12.05.2016, 17:31 **[ТС]**

Сообщение от LeniumSoft

Пиши.

20 штук? Серьезно? А не перебор?

Сообщение от insite2012

1. Я как-то не совсем понимаю, как можно начинать писать программу (сервис), не имея хотя бы более-менее четких установок. К примеру, я вот планирую написать одну прогу, по взаимодействию с сервисом. Первое, что я продумываю - это модели, которые будут в программе. Потом методы для работы с этими моделями. И потом уже как все это отобразить. Но писать вот так, без четкого плана - это как-то странно.

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

Сообщение от insite2012

2. Ну и далее, раз уж вы работаете с WCF. Определите одну модель, и в процессе написания меняйте в ней поля.

Я же вроде это в самом начале сказал.

Сообщение от Dark Byte

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

Сообщение от insite2012

Студия сама все сделает, вам надо будет только обновить ссылку на службу.

Не пользуюсь этим инструментарием в конкретно этом проекте... Во первых тут у меня так получилось что клиент является одновременно и сервером. Во вторых я пока что пишу ViewModel, а интерфейс недописан и мне не на что повесить запуск сервера для обновления ссылки. И в третьих Mex в конечном счете все равно пришлось бы выпиливать потому что эта пакость требует админских прав, которые мне никто не даст в универе где надо будет запускать.

Сообщение от insite2012

Еще вариант - использовать известные типы

Кто же напишет известные типы для моих целей?

Сообщение от insite2012

возможно вместе с реализацией IExtensibleDataObject

Интересная штука, хотя я пока не очень понял для чего она. Раньше не слышал про нее.

@insite2012 · 12.05.2016, 17:40

Сообщение от Dark Byte

Кто же напишет известные типы для моих целей?

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

Сообщение от Dark Byte

Интересная штука, хотя я пока не очень понял для чего она

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

@Usaga · 13.05.2016, 04:53

Dark Byte, как-то давно, мы делали приложение для работы с вот этим API. Функций там малый миллион. Так вот, ребята разработавшие это API, видимо очень хорошо подумали мозгом головы и выдали API не использующее DTO вообще (всё на примитивах .NET). При этом только небольшое количество функций имеет больше пяти аргументов, а так, в среднем, 2-3 аргумента.

Работая с этим API ни кто не выбросился в окно с криком "как же неудобно работать с таким количеством аргументов!".

Так, что либо смирись с тем, что твой сервис требует много вводной информации, либо пересмотри архитектуру сервиса и его контрактов.

Новые блоги и статьи Все статьи Все блоги /
Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка библиотек: SDL3, Box2D, FreeType, SDL3_ttf, SDL3_mixer и SDL3_image из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .
Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.

@Dark Byte 30 / 47 / 19 Регистрация: 23.10.2014 Сообщений: 1,001

	Как удобнее передавать большое количество параметров? 12.05.2016, 14:44. Показов 4452. Ответов 12 Метки нет (Все метки) В продолжение этой темы. Я пишу WCF сервис и у меня очень много функций с похожими аргументами. Т.е. какие то аргументы совпадают и по именам и по типам, а какие то нет. Причем в каждой функции прилично аргументов где то от 2х до 5. Плюс я вот все еще пишу его, поэтому иногда где то добавляются аргументы, иногда убираются. Поэтому мне не удобно каждый раз везде менять прототипы. Я пока что сделал просто общий класс в который сложил все аргументы и передаю параметром. Т.е. те которые не используются остаются null при вызове. Но это тоже не очень удобно выходит, хотя бы потому что поди вспомни в какой функции у тебя какие параметры передаешь. В общем нельзя ли как то более удобно это сделать? С грустью вспоминаю о C# 7.0, там можно было бы удобно очень кортежи заюзать... Но поскольку он пока не доступен... 0

@Usaga 14293 / 9378 / 1352 Регистрация: 21.01.2016 Сообщений: 35,345
	12.05.2016, 15:19
	Dark Byte, по хорошему, повторяющиеся параметры можно и нужно упаковывать в DTO. Там, где используется всего 2 или 3 параметра, можно обойтись и без DTO. Не вижу в этом особой проблемы. Есть вероятность, что у тебе нужно пересмотреть архитектуру своего сервиса и его контрактов. Если есть желание творить лютый говнокод, то можно сделать упор на Tuple. 0

@insite2012 5548 / 4311 / 1218 Регистрация: 12.10.2013 Сообщений: 12,371 Записей в блоге: 2
	12.05.2016, 17:12
	Dark Byte, два замечания. 1. Я как-то не совсем понимаю, как можно начинать писать программу (сервис), не имея хотя бы более-менее четких установок. К примеру, я вот планирую написать одну прогу, по взаимодействию с сервисом. Первое, что я продумываю - это модели, которые будут в программе. Потом методы для работы с этими моделями. И потом уже как все это отобразить. Но писать вот так, без четкого плана - это как-то странно. 2. Ну и далее, раз уж вы работаете с WCF. Определите одну модель, и в процессе написания меняйте в ней поля. Студия сама все сделает, вам надо будет только обновить ссылку на службу. Еще вариант - использовать известные типы, возможно вместе с реализацией IExtensibleDataObject (при добавлении ссылки на службу Студия сама реализует его в контрактах данных на стороне клиента). В общем, инструментов вполне достаточно. Пробуйте, используйте. 0

@Usaga 14293 / 9378 / 1352 Регистрация: 21.01.2016 Сообщений: 35,345
	13.05.2016, 04:53
	Dark Byte, как-то давно, мы делали приложение для работы с вот этим API. Функций там малый миллион. Так вот, ребята разработавшие это API, видимо очень хорошо подумали мозгом головы и выдали API не использующее DTO вообще (всё на примитивах .NET). При этом только небольшое количество функций имеет больше пяти аргументов, а так, в среднем, 2-3 аргумента. Работая с этим API ни кто не выбросился в окно с криком "как же неудобно работать с таким количеством аргументов!". Так, что либо смирись с тем, что твой сервис требует много вводной информации, либо пересмотри архитектуру сервиса и его контрактов. 0