Maa-Kut

Использовать javascript: по мере заполнения полей формы сохранять значения где-нибудь в куках, а при открытии страницы читать значения из кук и подкладывать в пустые поля.

Полагаю, в Business Layer, т.к. объекты домена - это объекты, моделирующие сущности предметной области; они включают в себя и нужные данные, и соответствующее поведение. В DAL им особо делать нечего, там нужны только данные, подлежащие сохранению.

Работа с БД на сегодняшний день хорошо обеспечивается целой плеядой всевозможных ORMов; можно даже SQL не знать: тягай себе сущности простыми Linq-запросами и радуйся. А у очень многих веб-приложений логика работы с БД сводится к простому CRUD, т.е. никаких зубодробительных хранимок и сложносочиненных транзакций писать не приходится. Если взять EF Code First, то даже базу руками создавать не надо. В общем, не вижу проблемы.

Что до проектирования, то тут разочарую. Программист, который не умеет проектировать (хотя бы на каком-нибудь уровне), - это не программист, а мелкий кодер (ненамного выше уровнем, чем секретарша-машинистка). И уход во фронт - не панацея, т.к. современный фронт - это километры скриптов и всевозможные фреймворки. Т.е. там тоже придется проектировать, и немало (иной раз похлеще, чем в бэке - зависит от специфики приложения).

Если бизнес-логику рисовать совсем невмоготу, то остается скинуть это на кого-то другого. Кто-то другой сделает все нужные сервисы, работу с БД и другими источниками данных и эти сервисы вам предоставит в виде библиотеки, WCF-сервиса, через REST или еще как-то. Ну а вам останется нарисовать на ASP.NET фронт, в нужных местах сервисы подергивая. В принципе, в больших проектах подобное разделение на программистов фронта и бэка вполне себе применяется и часто бывает оправданно.

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

Притча в тему:

Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?

Программист: ну представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер.» Выясняется, что он в следующей главе облокачивается о столб, которого уже нет…

Потом, есть еще традиционный вопрос заменяемости компонентов. Скажем, сегодня у нас View - это веб-интерфейс. А завтра заказчик захотел, скажем, десктопный клиент или клиент в виде Android-приложения. А у нас уже Business на веб завязан. Или Data использует какой-нибудь NHibernate, который захотели заменить на EF. Но фиг там - в Business вовсю хвосты NHibernate торчат, и теперь надо полсистемы переписывать.