У меня есть уровень доступа к данным, уровень обслуживания и уровень представления. Уровень представления - это ASP.NET MVC2 RTM (веб), а уровень обслуживания - WCF (службы). Это все .NET 3.5 SP1.

Проблема в том, что в сервисах возвращаемые объекты помечаются[DataContract] приписывать. В Интернете используется SessionStateProvider AppFabric Cache (a.k.a Velocity) для хранения состояния сеанса. Из-за этого все, что я храню в сеансе, должно быть сериализуемым.

Здесь возникает проблема: DataContracts не помечены[Serializable] и, насколько я помню, вводя его в класс, уже отмеченный[DataContract] возникают некоторые проблемы, и поэтому я не верю, что это решение.

Первоначально я планировал использовать DataContracts прямо в веб-слое, используя их в качестве моделей для представлений, связанных с рендерингом DataContracts (возможно, вложенных в класс ViewModel более высокого уровня). Но из-за того, что поставщик состояния сеанса требует, чтобы все объекты, хранящиеся в нем, были сериализуемыми, я начинаю переосмысливать эту стратегию. Было бы неплохо иметь, хотя, так как они содержат логику проверки с использованиемIDataErrorInfo интерфейс, и та же логика проверки может быть повторно использована в MVC как часть привязки модели.

Что, по вашему мнению, является лучшим способом, позволяющим мне сократить необходимую работу?

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

A. Создайте часть «ServiceIntegration» в веб-проекте.

Это был бы посредник между моими контроллерами и моим сервисным уровнем WCF. Часть ServiceIntegration будет взаимодействовать с сервисным уровнем, используя DataContracts, и с веб-уровнем, используя ViewModels, но должна преобразовывать DataContracts и ViewModels, используя двусторонний Transformer.

Кроме того, поскольку проверка IDataErrorInfo не будет использоваться повторно, необходимо также создать валидатор для DataContract, который использует Transformer для преобразования из ViewModel в DataContract, выполнения проверки с использованием IDataErrorInfo и возврата результатов. Это затем будет использоваться внутри методов действия контроллеров (например,if (!MyValidator.IsValid(viewModel)) return View();)

Требуются разные классы: xDataContract, xViewModel, xTransformer, xValidator

Б. Создайте часть «SessionIntegration» в веб-проекте.

Это будет посредник между контроллерами (или чем-либо, осуществляющим доступ к сеансу) и самим сеансом. Все, что требует доступа к сеансу, проходит через этот класс. DataContracts будет использоваться во всем приложении, если только они не сохраняются в сеансе. Часть SessionIntegration будет нести ответственность за преобразование DataContract в некоторую ISerializable форму и обратно. Дополнительный валидатор не требуется из-за использования интерфейса IDataErrorInfo в DataContract.

Требуются разные классы: xDataContract, xTransformer, xSerializableForm

Примечание: в обоих сценариях все еще будут присутствовать ViewModel, однако с помощью (B) я смогу составить ViewModel из DataContracts.

(B) имеет то преимущество, что не нуждается в дополнительном валидаторе.

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

Спасибо,

Джеймс