>Так и оторвать. В том смысле, что клиент не должен обращаться к БД напрямую, не должен содержать SQL-запросов. >Предполагается, что между БД и клиентом находится сервер приложений, относительно которого БД находится локально. Хотя для большей производительности БД и может крутиться на отдельной машине, но с ней общается только сервер приложений, а клиент о ней вообще знать не обязан. Ну да, именно это я и имею в виду. >Соответственно, при такой архитектуре клиент и вовсе может быть «тонким», т.е. набором веб-страниц. Это у нас фактически было раньше, но практика показала, что веб-страницы — это неудобно (даже если это SmartGWT). Решили делать на клиентской стороне полноценное приложение на Swing. >Если же вы делаете «толстый» клиент, то по всей видимости, серверное приложение у вас будет набором веб-сервисов. Серверное приложение должно отрабатывать запросы клиента, делая свои запросы к БД, преобразовывая данные и отдавая их клиенту.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 05/02/2012 13:18 (UTC)В том смысле, что клиент не должен обращаться к БД напрямую, не должен содержать SQL-запросов.
>Предполагается, что между БД и клиентом находится сервер приложений, относительно которого БД находится локально. Хотя для большей производительности БД и может крутиться на отдельной машине, но с ней общается только сервер приложений, а клиент о ней вообще знать не обязан.
Ну да, именно это я и имею в виду.
>Соответственно, при такой архитектуре клиент и вовсе может быть «тонким», т.е. набором веб-страниц.
Это у нас фактически было раньше, но практика показала, что веб-страницы — это неудобно (даже если это SmartGWT). Решили делать на клиентской стороне полноценное приложение на Swing.
>Если же вы делаете «толстый» клиент, то по всей видимости, серверное приложение у вас будет набором веб-сервисов.
Серверное приложение должно отрабатывать запросы клиента, делая свои запросы к БД, преобразовывая данные и отдавая их клиенту.