Преобразование данных из объекта класса A в объект из класса B - PullRequest
0 голосов
/ 11 апреля 2011

У меня есть три разных класса:

Task
Order
Transmission

У каждого класса есть свойства с разными типами.Также есть возможность прикрепить данные, которые представлены пользовательскими полями (реализуется массивом IField, где IField может быть текстовым полем или полем списка).Каждое настраиваемое поле имеет имя, представляющее имя присоединенного свойства данных.

Мне нужно преобразовать один класс в другой:

Task -> Order
Order -> Transmission
Transmission -> Task
Transmission -> Order
Order -> Task
Task -> Transmission 

для того, что я создал:

  1. Статический класс статических ключей, где каждый ключ представляет имя свойства.
  2. "DataObject", который содержит словарь имени свойства и объекта в качестве значения.
  3. Каждый класс (Task, Order, Transmission) реализует интерфейс IDataShare:

    public interface IDataShare { DataObject ToDataObject(); void FromDataObject(DataObject data); }

Например, объекты задач со следующими свойствами:

WorkerId:5
CustomerId:7
VehicleId:null
StartDate:null

И со следующими настраиваемыми полями:

Subcontractor: {listId:5, Value:4} (this is list field)
delivery Note: "abc" (this is text field)

будет преобразовано в следующий словарь:

{"WorkerId", 5}
{"CustomerId", 7}
{"VehicleId", null}
{"StartDate", null}
{"Subcontractor", {listId:5, Value:4}}
{"delivery Note", "abc"}

строковые ключи "WorkerId", "CustomerId"," VehicleId "," StartDate "были взяты из статического класса, который содержит строковые константы, где" Subcontractor "и" deliveryNote "- это имена пользовательских полей, добавленных пользователем (я не знаю, какие поля пользователь может добавить, поэтому япросто используйте имя поля).Когда я заполняю объект с помощью DataObject, я должен убедиться, что имя свойства совпадает с именем ключа, а также убедиться, что значение верное (строка не может быть вставлена ​​в long).Кроме того, настраиваемое поле списка (субподрядчик) не может иметь только itemId в качестве значения, потому что, когда мне нужно убедиться, что listId настраиваемого поля в объекте совпадает со listId настраиваемого поля в DataObject.

У меня много проблем со знанием типа значения.Я всегда должен использовать «X - Y», если операторы «X как Y».Кроме того, я должен помнить, как хранить тип значения при реализации интерфейса IDataShare, который усложняет работу.

Может кто-нибудь помочь мне подумать об ограничении, которое я могу добавить к процессу преобразования из объекта в DataObject?Кто-нибудь может помочь мне улучшить этот метод преобразования объектов?

Спасибо!

ОБНОВЛЕНИЕ
Я хочу объяснить точку.Моя самая большая проблема заключается в том, что есть несколько способов перевести каждое свойство / настраиваемое поле, поэтому мне нужно запомнить тип значения в DataObject.Например, в классе Transmission у меня есть свойство VehicleId.Я хочу преобразовать объект задачи с настраиваемым полем с именем «VehicleId» в Transmission.Все, что я хочу, это то, что значение пользовательского поля TaskId VehicleId будет преобразовано в свойство VehicleId Transmission.Но, поскольку это настраиваемое поле - как я писал ранее - есть способ сохранить настраиваемое поле, основанное на list: {listId:5, Value:4}.Теперь в процессе преобразования (FromDataObject in Transmission) в случае, если DataObject имеет ключ «VehicleId», я должен проверить, является ли значение длинным (идентификатор транспортного средства в качестве свойства) или IListField (идентификатор транспортного средства в качестве настраиваемого поля списка).эти проверки типа действительно делают беспорядок.

Ответы [ 3 ]

1 голос
/ 11 апреля 2011

Что ж, если количество классов, между которыми вы конвертируете, действительно ограничено, как вы сказали, могу ли я просто написать операторы приведения для ваших классов?

http://msdn.microsoft.com/en-us/library/xhbhezf4%28v=VS.100%29.aspx

Кажется, что логики, которую вы вкладываете в преобразование, достаточно, чтобы оправдать что-то подобное.С другой стороны, кажется, что есть базовый набор полей, используемых в разных объектах, и вы просто вставляете их в нетипизированный словарь.Если поля являются общими для всех типов, можете ли вы использовать преобразование в строго типизированный общий объект?В связи с этим возникает вопрос: не могли бы вы использовать общий объект базового класса?

Если у вас есть варианты изменения определений «Задача», «Порядок» и «Передача», я бы снова посмотрел на них.Такой сценарий выглядит как «запах кода».

0 голосов
/ 11 апреля 2011

Рассматривали ли вы использование дженериков?

Если Задача, Порядок и Передача все наследуются от базового класса, такого как Property, то вы можете предоставить общий метод для получения нужных значений.GetMyValue () где T: свойство

Не очень ясно, чего вы пытаетесь достичь.

0 голосов
/ 11 апреля 2011

Если я правильно понимаю, ToDataObject - это в основном сериализатор, а FromDataObject - десериализатор.Если данные, содержащиеся в этом объекте, совместимы по типу, то кажется, что сам факт сериализации их в нетипизированные данные является источником вашей проблемы.Зачем делать это, а не просто сохранять данные в своем родном формате?

Если вам нужно использовать адаптер из-за несовместимости между объектами, которые не могут быть разрешены по какой-либо причине, я думаю, вы можете создать такой, который по крайней мере сохранит данные в своих собственных структурах вместосериализует все в строку.Словарь в C # может содержать что угодно, как минимум, вы можете использовать Dictionary<string,object>.

Также неясно, что означает вся эта проверка - почему данные будут несовместимы, если вы отображаете свойства одного и того же объекта?типы данных?Например, если предположить, что это внутренний процесс, при каких обстоятельствах (например) string из одного объекта может пытаться быть назначенным long в другом объекте?Кажется, что это было бы необходимо, только если данные были строго напечатаны в одном объекте, но не в другом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...