n-уровневая архитектура с Silverlight, WCF и nHibernate - PullRequest
4 голосов
/ 28 января 2010

Я пытаюсь настроить чистую и гибкую прикладную среду для приложений, ориентированных на данные, с интерфейсом только для silverlight. Я хочу иметь строгое разделение проблем и хочу быть максимально гибким (например, обмениваться ORM позже), при этом уменьшая объем кода.

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

Вот как выглядит мой обозреватель решений:

  • MyCompany.MyApplication.Entities
    Библиотека классов - проект, который содержит только доменные (бизнес) объекты, такие как Клиенты, Адреса и т. Д. Это POCO с атрибутом [Serializable] -, но не любой другой код. Все свойства помечены как виртуальные, чтобы классы могли получать и перезаписывать свойства.

  • MyCompany.MyApplication.DataAccess
    Библиотека классов - проект, который содержит специфичный для nHibernate код (Sessions) для загрузки, сохранения и удаления объектов домена. Этот проект имеет ссылки на Entities-проект, а также на nHibernate-библиотеки.

  • MyCompany.MyApplication.Core
    Библиотека классов - проект, который содержит бизнес-логику и часто просто отображает методы из DataAccess - проекта, такие как GetAllCustomers, SaveCustomer и т. Д. Имеет ссылки на Entities-проект и DataAccess-проект.

  • MyCompany.MyApplication.Web
    Веб-приложение - проект, в котором размещается клиентское приложение silverlight, а также WCF-сервисы для связи со стороной клиента. Чтобы предоставить доменные объекты клиентской стороне, эти классы являются производными, и все свойства перезаписываются и помечаются атрибутом [DataMember] -. Имеются ссылки на Entities-проекты и Core-проекты.

  • MyCompandy.MyApplication.Silverlight
    Sivlerlight 3.0 - проект, представляющий пользовательский интерфейс. Он содержит только сервисные ссылки на WCF-сервисы, предоставляемые веб-проектом. Реальные доменные объекты недоступны, но автоматически сгенерированные прокси-классы заменяют их.

Пожалуйста, скажите мне, что вы думаете об этой архитектуре, и если есть какие-либо конфликты! Еще один вопрос: есть ли способ избежать виртуальных свойств доменных объектов и необходимости перезаписывать их, чтобы сделать их доступными через WCF?

С уважением, Даниэль Ланг

1 Ответ

1 голос
/ 28 января 2010

Даниэль, ты не собираешься обходить требование виртуальных свойств nhiberante. Вы думали об использовании Dto's?

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