Стратегии для «всегда на связи» клиентской архитектуры Windows

Question

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

Меня попросили разработать приложение Windows Forms для нашей компании, которое взаимодействует с центральным (локальная сеть) Linux-сервером, на котором размещена база данных PostgreSQL.Приложение позволяет пользователям проходить аутентификацию в системе, а затем проводить обычные транзакции с базой данных PG.Обычно я предлагал бы написать приложение для веб-форм для Mono, но клиенты должны использовать локальные ресурсы, такие как периферийные устройства USB, так что об этом не может быть и речи.Хотя это может показаться неясным, мои вопросы выделены курсом ниже:

Дилемма # 1:

Приложение должно быть всегда подключено. Как мне структурировать мой DAL / BLL - должен ли он находиться на сервере или у клиента ?

Дилемма # 2:

Я читал о Службы клиентских приложений (CAS) , и кажется, что они отлично подходят для аутентификации, поскольку все предоставляется через URI.Я знаю, что для PostgreSQL существует поставщик данных .NET, но не слишком уверен, будет ли CAS работать на сервере Linux (Debian) ?Поверьте, я бы испачкал свои руки и попробовал сам, но мне нужно сначала придумать логический дизайн, прежде чем ресурсы будут выделены мне для «пробных целей»!

Дилемма № 3:

Если DAL / BLL должен находиться на сервере, могу ли я создать службы данных и предоставить только эти службы проверенным клиентам.Существует требование (безопасности), согласно которому строка подключения с именем пользователя и паролем к базе данных не может присутствовать ни на каких клиентских машинах ... даже если безопасность на стороне базы данных достаточно жесткая.Я предполагаю, что единственный способ для этого - создать различные методы службы данных CRUD, предоставляемые приложением ASP.NET, и заставить WindowsForms запросить данные или сохранить данные в приложении ASP.NET.(через URI), и они возвращают набор результатов или значение. Буду ли я прав, предполагая это?Должен ли я смотреть на службы данных WCF?и будет ли WCF работать с базой данных, отличной от SQL Server?

Спасибо, что нашли время, чтобы прочитать это, но знайте, что я отчаянно ищу любой совет по этому поводу!СПАСИБО МИЛЛИОНОВ !!!!

РЕДАКТИРОВАТЬ:

Я также рассматриваю возможность использования NHibernate в качестве ORM

Answer 1

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

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

Я не совсем знаком с CAS, но это выглядело, как AJAX, из того, что я видел на веб-сайте MSDN. Это может быть неправильно, но если это правильно, то у вас есть проблема в том, что такие запросы могут не иметь состояния, и это может быть проблемой, если вам нужно постоянное соединение.

В целом, исходя из того, что вы говорите, звучит более чистым, если вы используете двухуровневое, а не трехуровневое приложение и располагаете DAL / BLL на клиенте, возможно, при поддержке хранимых процедур на сервере. Затем вы можете настроить PostgreSQL для аутентификации на основе того, что вы используете в своей сети (KRB5, если я рекомендую AD). Это упрощает доступ к данным и позволяет управлять разрешениями на основе аутентификации в базе данных. Поскольку вы можете аутентифицировать пользователей на основе AD, вы можете установить соответствующие разрешения.

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