Есть куча сериализуемых классов сгенерированных xsd.exe. В какой понятный namespace их поместить? DTO? POCO? Что понятнее для англоязычного уха? В верхнем регистре или Pascal Case?

Здравствуйте, baranovda, Вы писали:

B>Есть куча сериализуемых классов сгенерированных xsd.exe. В какой понятный namespace их поместить? DTO? POCO? Что понятнее для англоязычного уха? В верхнем регистре или Pascal Case?

Я такие помещаю в пространство имён .Xml. Например, если бизнес-объекты в пространстве MyCompany.MyObjects, то Xsd генерит в MyCompany.MyObjects.Xml

Здравствуйте, _FRED_, Вы писали:

_FR>Я такие помещаю в пространство имён .Xml. Например, если бизнес-объекты в пространстве MyCompany.MyObjects, то Xsd генерит в MyCompany.MyObjects.Xml

А если потом решат на JSON перейти или бинарный протокол?

Здравствуйте, baranovda, Вы писали:

B>Есть куча сериализуемых классов сгенерированных xsd.exe. В какой понятный namespace их поместить? DTO? POCO? Что понятнее для англоязычного уха? В верхнем регистре или Pascal Case?

Например, DataContract или Interop.

Здравствуйте, baranovda, Вы писали:

B>Есть куча сериализуемых классов сгенерированных xsd.exe. В какой понятный namespace их поместить? DTO? POCO? Что понятнее для англоязычного уха? В верхнем регистре или Pascal Case?

А чем, собственно, aaa.bbb.ccc.Dto не устраивает?

Здравствуйте, AndrewVK, Вы писали:

_FR>>Я такие помещаю в пространство имён .Xml. Например, если бизнес-объекты в пространстве MyCompany.MyObjects, то Xsd генерит в MyCompany.MyObjects.Xml

AVK>А если потом решат на JSON перейти или бинарный протокол?

Недопонял суть вопроса: а в чём именно возникнет проблема?

Здравствуйте, _FRED_, Вы писали:

_FR>Недопонял суть вопроса: а в чём именно возникнет проблема?

Наверное в том, что неймспейс будет называться Xml, при том что никакого Xml нет. Или предлагается при переходе на другой формат сериализации менять и неймспейс?

Здравствуйте, AndrewVK, Вы писали:

_FR>>Недопонял суть вопроса: а в чём именно возникнет проблема?

AVK>Наверное в том, что неймспейс будет называться Xml, при том что никакого Xml нет. Или предлагается при переходе на другой формат сериализации менять и неймспейс?

Так и dto в этом случае будут другими, создаваться будут уже не Xsd, а чем-то ещё. А, может, в них, в dto, необходимости не будет и вовсе. пространство имён в этом случае означает то, чот в нём находятся объекты для Xml.

Так же, возможно, необходимо будет поддерживать сразу несколько протоколов сериализации. Например, "выхлоп" Xsd не размечает код для датаконтракта. В таком случае dto для одного и того же бизнес-объекта может быть несколько.

По факту, dto в явном виде мне нужны только для xml-сериализации (или совместимой с ней), потому что в коде уже мне удобнее работать с неизменяемыми объектами, без дефолтовых конструкторов и т.п. В случае использования бинарной- или датаконтрактной (без ограничения) сериализации с удаётся "передавать" сами бизнес-объекты, а вот именно там, где нужен для xml — приходится выписываьт специальные объектики.

Здравствуйте, _FRED_, Вы писали:

_FR>Так и dto в этом случае будут другими

Почему?

_FR>, создаваться будут уже не Xsd, а чем-то ещё

Ну и что? Что то мешает обеспечить совместимый с Xsd публичный интерфейс?

_FR>В таком случае dto для одного и того же бизнес-объекта может быть несколько.

Это лишает DTO какого либо смысла.

Здравствуйте, AndrewVK, Вы писали:

_FR>>Так и dto в этом случае будут другими
AVK>Почему?

Потому что Xsd не сможет сделать dto, подготовленные к json- или какой-либо другой технологии сериализации.

_FR>>, создаваться будут уже не Xsd, а чем-то ещё
AVK>Ну и что? Что то мешает обеспечить совместимый с Xsd публичный интерфейс?

Интерфейс чего? Интерфейс dto? Ничто не мешает. Ничто не мешает написать dto, которые могут подходящим образом сериализоваться во все необходимые форматы. Но помещать такие dto в пространство имён Xml будет странной идеей Но я же о другом случае говорил.

Когда появляются дополнительные требования к дто, очень может быть, что и сами dto придётся переписать и может даже контракты старые нарушить (потому что то, что генерит Xsd, при переписывании руками уж очень хочется сделать как-то поприятнее, например избавиьтся от массивов). А раз так, то и пространство имён можно будет сменить.

_FR>>В таком случае dto для одного и того же бизнес-объекта может быть несколько.
AVK>Это лишает DTO какого либо смысла.

ДТО-то да, лишает. Но это уже другая история. Например есьт сервис с небольшим, не развесистым интерфейсом (всмысле три-четыре метода), который возвращает-принимает очень уж развесистые объекты, где множетсво разнотипных свойств. И есть сторонние тулзы, которые автоматом генерят dto-шки каки-то только для xml, какие-то только для json и т.п. и я вполне готов допустить ситуацию, когда по различным причинам оказывается принято решение иметь несколько контрактов для каждого из видов "клиентов" по сути здесь получается — один клиент общается по джейсону, другой так. Странно конечно очень, но вай нот.

Здравствуйте, _FRED_, Вы писали:

AVK>>Почему?
_FR>Потому что Xsd не сможет сделать dto, подготовленные к json- или какой-либо другой технологии сериализации.

Ну так на xsd свет клином не сошелся.

AVK>>Ну и что? Что то мешает обеспечить совместимый с Xsd публичный интерфейс?

_FR>Интерфейс чего? Интерфейс dto? Ничто не мешает. Ничто не мешает написать dto, которые могут подходящим образом сериализоваться во все необходимые форматы. Но помещать такие dto в пространство имён Xml будет странной идеей Но я же о другом случае говорил.

Ты говорил ровно о том же. Есть некие dto, которые ты засунул в xml неймспейс. Потом мы меняем формат на json, пишем свой генератор, который плодит объекты, совпадающие по публичному интерфейсу со старыми, и вуаля, все остальное продолжает работать как раньше. Вот только неймспейс остался Xml, который в новой ситуации не пришей кой к чему рукав.

_FR>А раз так, то и пространство имён можно будет сменить.

А зачем его менять, если проще не придумывать пространству имен неудачные названия?

AVK>>Это лишает DTO какого либо смысла.
_FR>ДТО-то да, лишает. Но это уже другая история.

А другую историю ты можешь обсудить в другом топике.