:) ну я так подозреваю, что вы не поняли темы данной статьи. В этой статье разбирается ЕДИНСТВЕННО И ТОЛЬКО то как работать со строкой типа bank.aspx?bankId=2&branchId=12&cityId=120
пример призван ТОЛЬКО облегчить работу со значениями этих параметров и ничего более. Причем тут контролы, постбэки и то как чтото вводит пользователь? Страница - это черный ящик у нее на входе кроме всего прочего только строка url. Такая строка может быть образована в списке пунктов обмена для города у конкретного банка и сформирована обычными элементами Hyperlink или еще в миллионе случаев. Пример с биндингом строки запроса решает проблему определения в вашей бизнес-модели входных параметров строки запроса Url страницы.
Он должен делать только то, что делает: первый пример проверяет валидность объявленных свойств, второй проецирует строку запроса на свойства, заодно производя небольшую валидацию. первый пример (CheckNull) применим в любом классе C#, второй только в asp.net, посколько если вы внимательно посмотрите, ему передается экземпляр Page.
Я уже спрашивал: "расскажите мне как вы решаете задачу с работой строки запроса?". Как получаете параметры строки, как обрабатываете, как проверяете на наличие? Это тема не этого топика, но раз уж так получилось, ответьте здесь. Мне правда интересно. Я просто удивлен тем, что вы не понимаете, для чего может понадобится биндить параметры строки запроса на свойства страницы.
Спасибо, за замечание. Вы правы, конечно, в проекте типа Web App все работает в одном пространстве имен.
Не знал и не использовал, но похоже, такая конструкция может когда-нибудь и пригодится.
То есть вы изъясняетесь на своих собственных терминах, которые сами придумали.
Вопрос по MVC в этом теме вы вообще зря подняли, никаким боком в статье этот шаблон не затрагивается, не упоминается и не используется.
Поясните про IPostBackDataHandler, я не догнал вашу мысль, каким боком постбэки соседствуют со строкой запроса. Но стало интересно.
Спасибо за отличный комментарий!
По поводу третьего варианта: на самом деле в моем случае он как раз таки и не подходит. Задача стоит проверить валидность некоего свойства, логика обработки исключения должна уже исходить из контекста. Например вызов CheckNullMembers.Check(this.GetType().BaseType, this) можно заключить в try catch и поступать по ситуации. Считаю, что сама же проверка (Check) обязана выдавать исключение.
Кстати, по поводу исключений, я вчера специально почитал, что думает Рихтер и думает он так же как и я - все делать через исключения. Другое дело, что конечно же стоит отдавать предпочтение своим исключениям, но для моего примера объявлять еще и исключения - это лишнее, думаю.
Это довольно специфический материал. Кому он нужен - неясно. Этот опрос призван прояснить. Может статься, что сниппеты никому не интересны. Тогда и писать не имеет смысла.
Про Москву не скажу, но я видел ролик где здание (где-то зарубежом) тащили каким-то грузовиком и не так уж недалеко, а на пару километров (если не ошибаюсь). Скорость была ооочень низкая.
Это хорошо, но мой проект не подлежит локализации. И таких проектов в России, думаю, не так много (но они конечно есть и даже, вполне возможно, вы их разрабатываете).
Вот вы всюду перечисляете old-school и new-school. А что это за термины такие, кем определены, где про них почитать можно?
Контрол олицетворяющий post уже есть и это page.
Про какую модель вы говорите? Про вашу с контролом или про мою? В моем случае закладка никаким боком не выходит из сферы применения. Путь пользователь делает закладки, моему атрибуту все равно.
Риторика и философия... нарушение бизнес-правил - это исключительная ситуация. Как вам такое? Я за толерантность, используйте то, что удобно и к чему привыкли.
пример призван ТОЛЬКО облегчить работу со значениями этих параметров и ничего более. Причем тут контролы, постбэки и то как чтото вводит пользователь? Страница - это черный ящик у нее на входе кроме всего прочего только строка url. Такая строка может быть образована в списке пунктов обмена для города у конкретного банка и сформирована обычными элементами Hyperlink или еще в миллионе случаев. Пример с биндингом строки запроса решает проблему определения в вашей бизнес-модели входных параметров строки запроса Url страницы.
Я уже спрашивал: "расскажите мне как вы решаете задачу с работой строки запроса?". Как получаете параметры строки, как обрабатываете, как проверяете на наличие? Это тема не этого топика, но раз уж так получилось, ответьте здесь. Мне правда интересно. Я просто удивлен тем, что вы не понимаете, для чего может понадобится биндить параметры строки запроса на свойства страницы.
Рихтер, кстати говорит одну хорошую мысль: исключение в коде не означает только ошибку.
Не знал и не использовал, но похоже, такая конструкция может когда-нибудь и пригодится.
Вопрос по MVC в этом теме вы вообще зря подняли, никаким боком в статье этот шаблон не затрагивается, не упоминается и не используется.
Поясните про IPostBackDataHandler, я не догнал вашу мысль, каким боком постбэки соседствуют со строкой запроса. Но стало интересно.
Он станет ценным для меня, потому и выложен в персональном блоге.
По поводу третьего варианта: на самом деле в моем случае он как раз таки и не подходит. Задача стоит проверить валидность некоего свойства, логика обработки исключения должна уже исходить из контекста. Например вызов CheckNullMembers.Check(this.GetType().BaseType, this) можно заключить в try catch и поступать по ситуации. Считаю, что сама же проверка (Check) обязана выдавать исключение.
Кстати, по поводу исключений, я вчера специально почитал, что думает Рихтер и думает он так же как и я - все делать через исключения. Другое дело, что конечно же стоит отдавать предпочтение своим исключениям, но для моего примера объявлять еще и исключения - это лишнее, думаю.
Контрол олицетворяющий post уже есть и это page.
Про какую модель вы говорите? Про вашу с контролом или про мою? В моем случае закладка никаким боком не выходит из сферы применения. Путь пользователь делает закладки, моему атрибуту все равно.