Как предоставить общий код между WPF и ASP.NET MVC-приложением?

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Я действительно нашел Rocky Lhotka книги, программное обеспечение и видео по этой теме очень полезно. Вот несколько ссылок на его содержание:

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& то есть = UTF-8 & QID = 1331834548 & ср = 1-2

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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