Возможные подводные камни архитектуры

Question

В настоящее время я создаю довольно сложную систему CRM / POS, которая соответствует следующим требованиям:

1. Система должна быть в состоянии быть установлена ​​на одном компьютере (ПК)
2. Система должна быть в состоянии быть установленной на 1 машине, которая может выступать в качестве сервера, и быть доступной для нескольких клиентских машин (локальной сети, проводной и беспроводной)
3. Система должна работать без подключения к Интернету

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

Архитектура, на которой я остановился, выглядит следующим образом:

• Sql Server 2008 Express DB
• Уровень данных Linq-To-Sql
• Службы WCF, предоставляющие уровень данных linq
• WPF для внешнего интерфейса

Это должно поддерживать все 3 требования, и я надеюсь предоставить довольно простой порт из WPF в Silverlight для веб-фазы 2.

Мой вопрос: есть ли проблемы с выбранной архитектурой? Я широко использовал asp.net и Windows Forms, но у меня мало опыта в WPF (выбрал его для графических возможностей). Есть ли проблемы с привязкой Linq-To-Sql в WPF через WCF?

Answer 1

Поскольку позже вам понадобится веб-решение, почему бы не установить IIS на одном компьютере, чтобы решение для одного компьютера также было «веб-ориентированным».

Затем вы можете использовать Silverlight с первого дня. Однако нужно ли в пользовательском интерфейсе на системе с одним ПК делать что-либо, что не может сделать Silverlight?

Вы бы предпочли быстро выпустить версию для одного ПК, а затем испытывать трудности с портированием на развернутое в сети решение или же вам не терпится начать с самого начала?

Answer 2

Я недавно изучил это и пришел к выводу, что Entity Framework лучше расположен между базой данных и WCF / WPF. Статья Entity Framework в многоуровневых архитектурах была важна в моем процессе принятия решений. Также, возможно, лучше изначально использовать независимый от БД подход.

Теперь, когда я собрал большую часть приложения (DB-> EF-> WPF-приложение для настольных компьютеров), я все еще счастлив, что ушел с EF. EF выполняет большую часть основной работы для меня, и я думаю, что он очень хорошо отображает реляционную и объектно-ориентированную работу.

Если вы собираетесь публиковать веб-версию с использованием silverlight, я бы прислушался к совету , чтобы начать с создания обеих версий как части вашей архитектуры. Это трудно сделать ретроспективно. См. Повторное использование кода в WPF и Silverlight 2 .

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

Answer 3

Несколько мыслей:

Если вы планируете порт из WPF в Silverlight, я бы порекомендовал следовать шаблону раздельного представления, например MVVM. В зависимости от сложности пользовательского интерфейса следование руководству PRISM и многоцелевой подход к разработке как для WPF, так и для SL может сэкономить вам некоторое время в долгосрочной перспективе. Или же вы можете полностью отказаться от WPF и разработать SL-приложение вне браузера с самого начала - два диалекта и инструментария XAML становятся все ближе. Однако это может усложнить ваши «отключенные» сценарии.

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