Как разделить большую часть кода между WPF и приложением ASP.NET MVC?

Question

Какую архитектуру и шаблоны я могу использовать для совместного использования большей части модели и логического кода между WPF и приложением ASP.NET MVC?

Я пытаюсь достичь чего-то большего, чем просто разделение объектов данныхиз двух презентационных проектов.Существует гораздо больше общего, например, логика пользовательского интерфейса в отношении того, что отображается при каких условиях, когда что-то требуется, и т. Д., Которые я хотел бы сохранить в общем коде.

ADDED: Я только начинаю по-настоящему любить концепцию моделей представлений, независимых от моей модели сущности, которая ведет мою презентацию.Хотя некоторые из аннотаций, используемых в них, расположены в сборках, специфичных для MVC, ни одна из предоставленных метаданных на самом деле не относится к сети.Я бы очень хотел изучить использование моих моделей представлений MVC в качестве источников данных для привязки к представлениям WPF.Любые предложения по этому вопросу будут оценены по достоинству.

Answer 1

Моя личная любимая конфигурация аналогична предложенной Адамом Кингом, но мне нравится сохранять логическую библиотеку DLL как часть веб-проекта. Я запускаю проект под названием CT Terminal , который следует этому шаблону. Мой проект Terminal.Domain содержит всю логику приложения и просто возвращает объект CommandResult со свойствами, которые действуют как инструкции, указывающие проекту пользовательского интерфейса, что делать. Пользовательский интерфейс полностью тупой и обрабатывает только то, что ему говорит проект домена.

Теперь, следуя подходу Адама Кинга, я вставлю эту DLL-библиотеку домена в приложение WPF, а затем закодирую пользовательский интерфейс, следуя инструкциям в возвращенном объекте CommandResult. Однако я предпочитаю другой подход. Я написал пользовательский интерфейс MVC 3 для предоставления JSON API. Этот API может использоваться любым приложением. JSON API был прост, потому что он был в основном оберткой вокруг моего проекта Terminal.Domain CommandResult object. Возвращаемый JSON будет иметь те же основные свойства. Таким образом, я бы написал приложение WPF для использования этого API, а не DLL. Теперь, если я внесу незначительные изменения во внутреннюю логику приложения, я просто разверну веб-проект на работающем сервере. Все клиенты, использующие API, автоматически получают эту новую логику.

Очевидно, что если вносимые изменения влияют на свойства, возвращаемые из API, то это потребует выпуска нового клиентского кода, но, по крайней мере, для внутренней логики вам не придется это делать.

Answer 2

Один из наиболее широко используемых шаблонов, по-видимому, имеет сущности в отдельной сборке DLL, а затем ссылается на нее из каждого из других проектов.

MVC 3 очень хорошо подходит для шаблона хранилища, чтобыть чистым маршрутом для первого использования и будет работать как для WPF, так и для ASP.net

Answer 3

Мне действительно очень понравились книги, программы и видео Рокки Лотки по этой теме.Вот несколько ссылок на его содержание:

http://www.lhotka.net/

http://channel9.msdn.com/Events/Speakers/Rockford-Lhotka

http://www.amazon.com/Expert-C-2008-Business-Objects/dp/1430210192/ref=sr_1_2?s=books&ie=UTF8&qid=1331834548&sr=1-2

Answer 4

Вы пытались использовать Переносимые библиотеки классов .При этом вы можете создать слой данных и использовать его в ASP.Net MVC, WPF, Windows Phone, Silverlight.

Answer 5

Используйте Web Api, пусть и WPF, и веб-приложение используют сервисы Web Api.Готово.

Answer 6

Начиная с очевидного. Инкапсулируйте свою бизнес-логику и модель предметной области в отдельную сборку.

Что касается уровней представления и общего поведения пользовательского интерфейса, то ближе всего вы получите парадигму проектирования MVVM, реализация будет C # в WPF / XAML и Javascript для веб-интерфейса ASP.NET MVC.

Для веб-интерфейса вы можете приблизиться к WPF (MVVM) способу работы с http://knockoutjs.com/, написанным Стивом Сандерсоном из Microsoft. Это MVVM для браузера. Также проверьте http://www.asp.net/mvc/mvc4 для получения дополнительной информации.

Answer 7

Создайте сервисный уровень для вашего приложения, указав интерфейсы с методами, которые представляют все операции, которые вам нужно выполнить. Кроме того, на этом сервисном уровне определите все типы данных, используемые приложением. Эти классы типов данных должны содержать только свойства, а не операции. Поместите эти интерфейсы и классы в сборку самостоятельно. Эта сборка должна использоваться совместно вашим веб-приложением, приложением WPF и кодом, который ее реализует.

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

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