а ты знаешь разницу между Server Side и Client Side ??? AFAIK, браузеры не держат в памяти весь документ.
А я говорил о Server Side. Компьютеры на хостинге тоже не всемогущие ;о)


Тогда за тебя уже все придумали. Эта штука называется Skin или Themes. 


Прямого доступа к СУБД у тебя никогда не будет. Всегда используются провайдеры для доступа к базе. Точнее для коннекта к базе. Констрейнты хранятся в СУБД и являются ее внутренней архитектурой.
А что касается логики работы или доступа. Ну-у-у-у. Вобщем-то уже давным-давно благодаря тому что asp.net может использовать бинарный код. Они хранятся с отдельных сборках... 
И вообще можно использовать ObjectDataSource для связи данных. 

  Repeater или DataList, или GridView/DataList они что, они не унифицированные ???   Ты к ним можешь прикрутить любой контейнер с данными.

2 Mymik

Полемика интересная получается  
К сожалению, самый большой недостаток людей заключается в том, что у каждого , абстрактно конечно, своя терминология и взгляд на мир вогкруг.
С твоей стороны, не очень красиво выглядит, что в своей аргументации используешь понятия, на правомерность которыйх я не посигал.  
Во- первых, что такое сайд и бесайд я в курсе, что такое AFAIK я в душе не представляю  
Во-вторых, шаблоны, ака templates используются по-умолчанию, т.к при выводе любой дата-строки существует шаблон вывода и вообще у каждого асп контрола есть шаблон вывода.
В третьих эти встроенные шаблоны меня есессно не устраивают
В четвертых, речь идет, опять же абстрактно,( боюсь задеть кого нить- своей кривой манипуляцией терминов)
о своего рода PageFactory, ControlFactory/
В пятых, повсеместен подход в разработке - ват я си ват ю гет, я имею в виду рапид средсва и методы, в которых пропагандируются разложение сложного на простое, но за счет этого дико увеличивается количество контента - исходных страниц и контролов, хотя можно было бы обойтись без некоторых ( экономия всего-лиш 20-30 %, ни на что большее не претендую, к тому же повышается требование к разработчику, так как maintanance таких проектов может усложниться)
В шестых, пробежимся по критике:
Skin или Themes - ни чего путного не скажу, признаю, не знаком, обязательно в ближайшее время ознакомлюсь
В седьмых нащет логики работы, не правильно выразился, - я имел всего-лишь то, что шаблон сам должен расставлять значения в свои поля(это самое узкое место), а не из-вне, ниже приведу пример.
В восьмых,

ясен пень, что унифицированные
Но множество методов всегда приходится дописывать ручками - листать\не листать, видеть\не видеть, PageSize... РАЗ
Для каждого контента внутри листателя- своя логика работы - два
я сам всегда использовал репитеры, но ведь придумали же вью - три - это я к тому, что листателей несколько видов, несовместимых, а контент - шаблон- template - может быть один
Отсюда - унификация, как я говорил - есть способ абстрагироваться от типа листателя и вообще(если запись одна)
Есть такое понятие TemplateView- Мартин Фаулер - Архитектура корпоративных приложений,
А что есть паттерны? Уж точно не движение в сторону упрощения понимания.

Чтобы не показаться голословным, приведу пример того что получается, надеюсь услышать критику по примеру, а не по мне  

Вот у нас есть страничка, в ней контрол

Вот у нас шаблон вывода, в нем Лэйбл

А вот бихайнд код для этого шаблона вывода


Далее Контрол - листатель
Причем заметьте, что в             <ItemTemplate /> пусто                       



Ну и код для него


ну пока вот так вот, теперь можно и поговорить конкретнее  

В жизни не подумал бы, что это недостаток :о)   
Но не будем философствовать на тему сотворения мира.

As Far As I Know

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


Мне кажется предыдущие два высказывания противоречат друг другу. Как твое решение, так и паттерны, это очень узкоспециализированное направление. Просто паттерны упрощают работы с большим количеством классов. А твое решение будет упрощать работу с большим количеством листателей. Это действительно нужно при очень большом и громоздком портале. Где нужно изменить шаблон в одном месте и чтобы он опосля поменялся во многих местах. 


Твое подход узкоспециализированный и может с большим успехом применяться в огромных проектах. Где по какой-то лени разработчики не пошли решением создания отдельных UserWebControl'ов (в которых будет прикрепляться к листателю DataSource). А решили усложнить себе задачу и клепать Template программно. 
Это твое решение :о). Паттерны тоже для маленький проектов нецелесообразны.

Кстати. Ты говорил, что при разбиении на простые вещи, код увеличивается... В том примере что привел ты, кода пока что больше чем если пойти обычным решением.

Mymik, спасибо за понимание.



Это не плохо. Я не говорил, что это плохо. Я лишь указываю на тот факт, что если предложить разработчику способ А, который заметно проще способа Б (имею ввиду переход например от ASP к ASP.NET, использование MasterPage и другие новшества вообще),
то у разработчика "выключается" думалка, что естественно, у всех так(не будем вдаваться в философию).

Рассмотрим текущую ситуацию:
Известен факт, что раньше было Write("<html>"), в некоторых случаях до сих пор в респонсе так и генерируется страница, потом был предложен подход Jsp, php, asp - шаблонный, 
все бы хорошо, но эти представления начали засирать кодом скриптлетов(и до сих пор засирают),
на это было придумано вспомогательные объекты - Behind код, имеется в виду,
все бы хорошо,  
но теперь ВСЁ делается (я не говорю категорично, а лишь привожу пример) по этому шаблону

В чем смысл идеи(может быть уже давно придуманной до меня, я не претендую на патенты  )
в том чтобы чуть чуть отойти от методологии разработки веб, не делать всё в лоб,
(страница, -> вней контрол)

таких страниц, составных контролов накапливается куча ( в относительно больших проектах, согласен с тобой,Mymik)
Напрашивается идея освободиться от дублирующих друг друга страниц и контролов
Каким образом? программным by usage паттернов построителя и фабрики,
Которые какбы должны собирать контролы из множества других поменьше,
и ,соответственно, страницы из контролов
Вот это - проблема, надо думать
И уместен вопрос - а надо ли это, и где сдесь явная выгода?
Я интуитивно чувствую, что польза есть (согласен, могу ошибаться)
В чем сдесь подвох, по моему мнению?
В том, что девелоперы привыкли использовать построители и фабрики для невизуальных объектов,
а я в свою очередь оперирую как раз такими(в сущности xml-разметкой контролов),
которые отягощены behind кодом, своего рода такие "умные" картинки получаются

Есть смысл жить этой идее?
Или ну её и начать уже работать?