Всем привет!
Недавно начал разрабатывать сайт. 
Но что то мучает меня общас концепция его построения. 
Т.е. у меня есть хранилище данных - БД и по определенным алгоритмам юзер при переходе со страницы на страницу видит определеннное содержание. Параметры (id строки) для выборки данных из БД передаю как параметры адресной строки (Т.к. сайт не очень большой, то session решил не использовать). И далее в Page_Load заполняю определенным образом div теги на странице. 
Правилен ли такой подход? 
Какие вообще возможны идеологические подходы в построении сайтов???

Wanderer2019, Все что приходит от пользователя это ЗЛО. Потому надо как можно меньше давать ему вольностей в отправки всяких данные на сторону сервера. Ну и на стороне сервера естественно надо все проверять.

Если тебе не хочется передавать параметры через GET то можно использовать LinkButton и в обработчике событий на сервере передавать параметры через Cache(как альтернатива Session)



А что значит идеологический подход к построению сайта ??? Это как ???
Ну вообще как обычно, чем пользователь меньше видит тем лучше и для тебя и для пользователя. Дружественные friendly-links ипользовать. httpHundler используй(очень удобная штука, особенно когда AJAX ручками пишешь) если понадобиться.

Я пользователю не доверяю совершенно (сужу по себе) Потому в СУБД всегда одни хранимки. При передачи в СУБД обязательное System.Web.HttpUtility.HtmlEncode(). Если нужна какая-нибудь калидация на стороне клиента, то обязательно и на стороне сервера тоже ее выполняю (обычно достаточно Page.IsValid, но если CustomValidator то и на стороне сервера проверку пишу руками).

А вообще я не сильно все же понимаю что такое "идеология создания страниц",-   

А что значит friendly-links? это как? 
В мое случае получается что пользователь максимум что видит - это в строке адреса id-шники записей в таблице. 



какие минусы в хранении текста запроса к БД в .cs файле?



а это что такое ? и зачем нужно?



Это сообщение отредактировал(а) Wanderer2019 - 28.3.2007, 18:23

Когда кто-либо говорит про трехзвенную архитектуру и сравнивает ее с клиент-серверной архитектурой, то это примерно выглядит следующим образом:
"трехзвенная архитектура" - есть хранилище данных (1-е звено), есть сервер приложений (2-е звено), который выбирает из этого хранилища данные и определенным образом эти данные обрабатывает и после обработки конечный результат уже посылает на терминал клиента (3-е звено).
"клиент-сервер" - есть хранилище данных (сервер) и клиент, который с этого сервера выбирает данные с помощью определенного языка запросов (SQL).

Возможно данное определение технологии "клиент-сервер" и было правильным, но только очень давно. Когда еще не было нормальных баз данных, а были СУБД (навроде FoxPro) со встроенной поддержкой sql-запросов.

Более правильное описание технологии "клиент-сервер" следующее:
Есть хранилище данных (1-е звено) и клиент (3-е звено), который с этого сервера выбирает данные с помощью определенного языка запросов (SQL), но еще есть сервер приложений (2-е звено), уже встроенный в базу данных, с помощью которого можно обрабатывать данные любыми известными реляционной алгебре способами и уже после этого передавать конечный результат на клиента.

Так что закатывать глаза и говорить, что "трехзвенка это круто, не то что клиент-сервер" мягко говоря глупо. Каждая из этих технологий имеет свой круг применения. Трехзвенная архитектура, как правило, нужна только в случаях выполнения ОЧЕНЬ сложных обработок данных на серверной части.

Хранимые процедуры компилируются(что повышает скорость выполнения) и выполняют роль сервера приложений. С их помощью с данными можно делать все. Для этого достаточно вызвать заранее написанный код в виде хранимой процедуры со стороны клиента.

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



Дополнительное исключение возможныйых SQL-inj


Путешествуя по сети, нередко можно увидеть URL вида ‘/content.cgi?date=2000-02-21’ или ‘/article.cgi?id=46&page=1’. Подобного вида ссылки говорят о том, что полученный документ - есть результат работы скрипта на стороне сервера. Такая запись удобна с точки зрения сервера и еще может быть программиста, но что делать пользователям? Ведь в лучшем случае, в качестве параметров, передаваемых в URL, используются слова английского языка, как в приведенных случаях - date, page. Но и это совсем необязательно, т.к. вид передаваемых параметров в URL зависит только от чистоты совести проектировщика.

Кроме того, следует учитывать, что посетитель сайта с дружественным интерфейсом URL, постепенно привыкает к такой адресации и может осуществлять переходы в пределах проекта, видоизменяя URL вручную.

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

Это сообщение отредактировал(а) Mymik - 28.3.2007, 20:15

Mymik, 
Спасибо за помощь... 

еще один вопрос по поводу этих friendly-links... да, это конечно здорово, когда юзер не видит записи с огромным количеством параметров в URL. Но вот как этого добиться - непонимаю... как же передать тот же самый id записи на другую страницу? получается что только средлствами Cache или Session?
существуют ли какие то стандартные конструкции редиректа на другую страницу с парамеитрами???

Wanderer2019, 
http://www.codeproject.com/aspnet/URLRewriter.asp -- вот тут вот все описано как создавать и делать

http://www.google.ru/search?q=asp.net+url+...GL_ru__206__207 -- А вот сюда вот за доп информацией.

friendly-links не исключают передачу данные на страницу через параметры. Просто он делает это более красочно :о)