Дмитрий Ковальский

Если говорить про ASP.NET, который вы упомянули в комментариях -в своей практике наиболее часто встречал создание соединения непосредственно в методе, где исполняется запрос, с использованием синтаксического сахара using. Т.е. создали соединение,выполнили запрос, разорвали соединение. По PHP не скажу, но все же думаю вам надо для начала определится где вы будете писать ваш проект. Лично мне идея инициализации в конструкторе не нравится тем что есть ненулевая вероятность что соединение вы установите, возможно не используете никак, а когда оно будет закрыто не совсем понятно.

Покопайтесь здесь и здесь .

Касательно оплаты - вам нужна услуга эквайринга для физ.лиц. Самым крупным агрегатором таких услуг для физ.лиц недавно была Робокасса, но последнее время оттуда немало печальных новостей было как раз касательно отношений с физ.лицами. В принципе вы можете использовать ЯД,Вебманю, но поскольку большая(доминирующая) часть рынка интернет-платежей это банковские карты - вы покроете только маленькую часть потенциальных покупателей. Безусловно решения и костыли есть, но все же такую услугу проще получить будучи юридическим лицом.

В базе вам нужна таблица с данными в формате post_id, image_id. А где вы будете хранить изображения - другое дело. можно в файловой системе, можно в базе

На уровне базы данных такую склейку можно сделать только при условии что заранее известно в каких складах искать(Для этого делается последовательный JOIN одной и той же таблицы с разными sklad_id), или если заранее известен товар, по которому строится такая выборка( select по всем складам по id товара, затем PIVOT выборки).
Для сферического коня в вакууме на мой взгляд подойдет только свистопляска на уровне приложения.

Вы можете ваять что вашей душе угодно. К примеру вынести сущности авторизации и аутентификации в отдельные сущности из таблицы user. Различные свойства, будь-то имя, возраст и прочее можно хранить в формате user_id,property_id,value и тогда добавление новых свойств не потребует перестройки структуры таблицы.

Если в двух словах - это тенденция роста уникальных клиентов по неделям. Гуглить - "Нарастающий итог". Фактически к первой неделе джойнятся записи за первую неделю, ко второй - за первую и вторую и т.д. согласно условию tbl.[Week] >= t1.[Week]

Я конечно не гуру, но попробую озвучить свое мнение.
1)В общем и целом - да. Но что по вашему - короткий маршрут? короткие слова или малое число слешей? Тут все же качели читабельности неподалеку.
2)Я считаю да и причина довольно банальна - я не хочу лазить по всему проекту чтобы выяснить почему данный роут свалился в данный контроллер. Но есть исключение - регионы(Areas). У них свой RouteConfig и не исключено что он будет работать отлично от дефолтного.
3)Это вообще не проблема. Вам никто не запретит писать Javascript-логику, которая потом по ходу дела возьмет еще данных через API и сама нарисует view. Делайте как хотите, но это должно быть читабельно, поддерживаемо и хоть немного соответствовать поставленной задаче( не надо пользовать Angular только чтобы попользовать Angular)
4) Тут вы все в одну кучу смешали. Максимально короткими? В принципе да, но я хотел бы прочитав название точно угадать что он делает, а не узреть сюрприз в последствии. В остальном тоже соглашусь.
5) Предположим она нужна. Во первых уберите слово JQuery - сия библиотека к валидации имеет мало отношения. Во вторых на сервере как правило хватает проверок свойств ModelState.isValid и Model.isValid. Разумеется если ваша модель помечена всеми атрибутами, ограничивающими корректные значения. Тут правда есть одна заковыка - предположим у вас меняется логика валидации(поля обновились или еще какие-то телодвижения совершены). На практике вам нужно в двух местах обновлять одну и ту же логику, что не очень правильно(потенциальное дублирование кода, потенциальные ошибки забывчивости).
6)Может да, а может и нет. Повторюсь - клиентскую сторону можно лепить разными методами. Можно и Javascript-ом. В ASP.NET это не возбраняется. Это вообще нигде не возбраняется.
UPD:Программировать на C# внутри View не стоит. Тащить доп.данные тоже, хотя изредка такая необходимость возникает(словарь какой-нибудь подтащить). В основном код должен содержать вспомогательные функции- например сформировать какую-нибудь фразочку или проверить состояние объекта по нескольким полям вместо того чтобы писать кучу if в разметке.
END UPD.
7)Если честно не понял о чем вы.
8)Это не костыль, это транспортная система для коротких сообщений и простых типов. Использовать в качестве транспорта для модели тоже можно, но не безопасно с точки зрения приведения типов.
9) А что вы понимаете под "голый Ajax"? XmlHttpRequest? Да, на мой взгляд лучше его не использовать. Вторую часть вопроса не смогу комментировать без ответа на первую. Вьюшки бывают разные, некоторые подтягивают дополнительные данные по ходу дела. Тут нужно немного конкретики.
10) Не согласен и уже озвучивал ранее. Razor один из доступных инструментов. Можете использовать его - он хороший, а можете не использовать.