Обработка разных классов с одним и тем же именем в одном файле CS

Я использую две службы WCF, каждая из которых объявляет класс Donkey. Эти классы Donkey, хотя и идентичны по структуре, не относятся к одному и тому же типу из-за проблем с пространством имен.

До сих пор я использую using (как описано в здесь), но я чувствую, что хотел бы поставить его под более строгий контроль.

Любые предложения о том, как (и где) разместить преобразователь контракта данных, который сопоставляет оба класса Donkey друг с другом? Я знаю, что это немного глупый вопрос. Это связано с тем, что я не уверен, что это вообще возможно. Не стесняйтесь исправлять мою формулировку.

Все предложения приветствуются. Я подумываю написать свой собственный слой определения данных и создать свои, лучшие объекты Donkey (с выпивкой и проститутками, если кто-то осмелится использовать отсылку к Бендеру из Футурамы).


person Konrad Viltersten    schedule 05.08.2013    source источник
comment
Нельзя ли использовать разные пространства имен для двух наборов сгенерированного кода?   -  person Michael Gunter    schedule 05.08.2013
comment
@MichaelGunter Если я снова увижу безумно ужасно выбранные имена пространств имен (которые находятся в форме Something.SomethingElse.RandomNumber1234.SomethingHereToo.Donkey) более 5 минут, я собираюсь убить себя, вычеркнуть мои глаза, снова убить себя, пнуть маленькую собачку из чистой злости ко всему живому, а затем убить себя в третий раз. А вообще - да, могу. :)   -  person Konrad Viltersten    schedule 05.08.2013


Ответы (2)


Если я правильно понимаю вашу ситуацию, у вас есть две идентичные структуры разных типов, которые вы хотите использовать взаимозаменяемо. В этом случае все, что вам нужно, это определить неявные приведения типов. Итак, в одном определении Donkey определите приведение к другому Donkey и обратно.

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

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

person Rubixus    schedule 05.08.2013
comment
О контроле над оригинальными осликами не может быть и речи (ограничение времени отпуска/привилегий). Использование только одного или другого Donkey не вариант, потому что, по сути, у меня есть целая ферма - у меня сейчас до пяти Donkeys и скоро их станет больше. Таким образом, вспомогательный преобразователь осел-осел кажется хорошим вариантом (вставьте NS1.Donkey — вытащите другой NS2.Donkey). Однако @hunter, похоже, не одобряет эту идею. Я не уверен, почему. Комментарии? - person Konrad Viltersten; 05.08.2013

Явные пространства имен сделают свое дело.

Вы можете объединить свои классы Donkey, если они на самом деле одинаковы структурно, в другой проект, на который могут ссылаться два пространства имен.

Если у вас есть контроль над тем, как задуманы эти разрозненные Donkey классы, вы можете разрешить каждому из них совместно использовать интерфейс IDonkey, но это более или менее одно и то же синтаксическое решение для слияния.

person hunter    schedule 05.08.2013
comment
Я вообще не контролирую концепцию экземпляров Donkey. Не могли бы вы подробнее рассказать о слиянии двух классов? Я только что заметил, что классы могут содержать разную информацию. Вы имеете в виду разработку класса DonkeyBridge с двумя конструкторами, интерпретацию внутренних нативов во внутреннюю структуру данных и предоставление свойств для Donkey this и Donkey? такого типа? Это своего рода блестящая идея! Я должен был подумать об этом сам. Так что я украл его и присвоил себе все заслуги. :) Или вы что-то другое имели в виду? - person Konrad Viltersten; 05.08.2013
comment
То, что вы предлагаете, это третий осел, который противоречит законам природы. - person hunter; 05.08.2013
comment
Если бы вы создали DonkeyBridge, как бы вы его использовали? То, что вы делаете, действительно зависит от того, как вы собираетесь злоупотреблять этим Donkey - person hunter; 05.08.2013
comment
Я имел в виду, что у меня будет третий класс, который может принимать в качестве входных данных для конструктора любой из ранее существовавших классов Donkey и создавать новый экземпляр класса Donkey, который Прошу. У меня создалось впечатление, что вы имели в виду что-то другое под классом слияния. Пожалуйста, дополните. Спасибо. - person Konrad Viltersten; 05.08.2013
comment
под слиянием я имел в виду устранение двух других классов и создание нового класса. из ваших комментариев я вижу, что это невозможно. - person hunter; 05.08.2013
comment
О... Какой анти-кульминационный момент... Я полагаю, что преобразователь осла в осла снова на столе. Я чувствую себя ослом (другой способ сказать это, начиная с а) сейчас... - person Konrad Viltersten; 05.08.2013