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

Так вам же скриншот все написал. Что вы еще хотите? Согласно скриншоту - у вас модели явно описаны подходом CodeFirst, а показанный connection string имеет ссылки на модели сопоставления классов - сущностям в бд (DatabaseFirst). Тут или крестик или трусы. Насколько я помню подход CodeFirst - connection string должен содержать только расположение сервера БД и реквизиты, достаточные для манипуляции как с данными, так и со структурами таблиц. Касательно переноса - вообще проблемы не понял и не увидел, это уже какие-то ваши фантазии. Приложение содержит конфиг, в нем строки соединения с БД. Что еще вы хотите? Да, при деплое проекта - в полученном дистрибутиве, или что вы там надеплоите, будет конфиг, содержащий connection string

Очень странно звучит вопрос. Перед каждым unit-тестом не надо накатывать сервер БД. Только перед интеграционными и unit-тестами слоя доступа к данным.
В чем проблема? Если не знаете где писать - есть атрибуты методов вроде SetUp и TearDown в NUnit позволяющие писать любую логику формирования окружения для прогона тестов в рамках текущего класса тестов.
Если не знаете что писать - ну можно попробовать вызвать те же консольные комманды PowerShell. Либо более прямые инструкции

В данном случае ценность внешнего вида ваших моделей и View где-то около нуля. Покажите код, где вы извлекаете данные и код формирования модели. Да, и так, кстати - использовать EF в контроллере очень плохая идея пахнущая плохой архитектурой.

На мой взгляд здесь много разрозненных вопросов. Некоторые относятся к архитектуре приложения, некоторые к конфигурированию IIS, некоторые еще куда-то.
Касательно публикации самого приложения - это 2 кнопки и 3 галочки. Хотите большего? разбирайтесь с параметрами консольных команд msbuild - https://msdn.microsoft.com/ru-ru/library/ms164311.aspx.

Касательно EF - тут вообще все зависит от структуры базы, от внесенных изменений и вообще это вопрос деплоя и версирования БД. Чую у вас тут попахивает Code First с накатом структуры данных, вы отдали этот вопрос на откуп EF - значит разбирайтесь с EnityFramework на более глубоком уровне.Опять же это не совсем вопрос deploy.

Касательно IIS - что понимать под тонкой настройкой? https://msdn.microsoft.com/ru-ru/library/ms178477(... - Покопайтесь здесь

Касательно всего процесса - есть такая вещь как continuous integration. И такие решения как CruiseControl.NET и TeamCity. Это инструмент, который по факту обращения будет делать набор инструкций для деплоя вашего проекта(какие укажете). Например - собрать проект, прогнать тесты, если все хорошо накатить базу, если все хорошо - скопировать папку с файлами в директорию приложения и стартануть веб-сервер.

LINQ2SQL лучше вообще не использовать, особенно в команде на сколь нибудь крупном проекте.
EF - Рекомендуется для повсеместного использования в качестве ORM с небольшой сноской - если в вашем проекте нет требований по производительности взаимодействия с БД и если вы хотите быстро быстро на коленке сваять уровень взаимодействия с базой.
Для более эффективного взаимодействия с БД рекомендуются тонкие обертки над ADO.NET с вызовом хранимых процедур.

Практика не тащить данные, если они не нужны - хорошая. Практика - тащить данные для каждой строки - плохая. Вам бы просто объяснить как lazy работает коллеге.

Если вы хотите услышать ответ в форме - "в 2", "в 5", "в 1,5" то вынужден вас разочаровать. EF это витиеватая сложная обертка над ADO.NET сделанная с единственной целью - сделать вашу жизнь чуть попроще если вы плохо знакомы с техникой работы с базой данных. Технически она генерирует SQL запрос на основании ваших писулек и исполняет его на базе теми же классами и методами ADO.NET что и вы. Если вы хорошо пишете SQL-скрипты то разница в производительности будет только в обертках. Если вы хреново пишете скрипты и лепите курсоры, лишние JOIN-ы и еще ворох странных инструкций - то лучше возьмите EF. Если вы хреново пишете и серверный код, где сначала тащите всю таблицу данных к себе на сервер приложения, там ее фильтруете и сортируете, а затем отрезаете нужный кусочек - то вас и EF не спасет. В таком случае сгенерится фантастически неэффективный запрос с, возможно вынужденными, доп. запросами и при этом еще и само приложение получит задачи, которые ему даром не нужны. Нет хорошего ответа вроде "при миллионе записей пиши руками, а если меньше EF". Надо глобально смотреть на архитектуру приложения и взаимодействие с данными.

А что вы понимаете под "на лету"? Реакция на некое действие пользователя? Для 99,9% случаев - такое поведение не нужно. Нужно чуть чуть пересмотреть задачу и сделать без добавки столбцов. БД - вещь в высокой степени статичная должна быть. Исходя из этого можно заниматься ее оптимизацией работы.

Ну а если вы хотите накатывать обновления без остановки приложения, то банального ALTER TABLE вам должно хватить.

Вот вам маленькая загадка : если по каким-то причинам этот код выдаст исключение - вы будете знать в каком место оно возникло?
Последовательность LINQ-команд это конечно замечательно, но на мой взгляд этот код совершенно не читаем и с ходу понять что в нем не так на мой взгляд очень и очень трудно.
Если искать проблемы, то видимо у вас они кроятся в элементе "i.CommandId == x.HomeId" и "i.CommandId == x.GuestId". Какого типа эти поля? Что в них хранится и в каком виде?

UPD: Вы можете объяснить что у вас в конечном счете должно храниться внутри List< string > ? Что вы хотите сформировать ?

Беспокоитесь за производительность? пишите руками через SqlConnection/Command. Напишите Data Access Layer. Чем городить огород - займитесь разработкой простеньких оберток.

Ну нормализацию БД пока никто не отменил. Суть в том что может быть идентична, а может и нет. Простенький примерчик. Предположим у вас есть некая сущность, которая может пребывать в ряде состояний. Состояния описываются строками вроде "В ожидании", "Вот вот", "Уже опоздал". Скорее всего ваша Предметная модель описывает данный параметр как строку, а вот БД будет иметь представление как некий идентификатор на стороннюю таблицу со списком состояний. Другой пример. У вас есть сущность, которая описывается рядом свойств. Эти свойства хранятся следующим образом : есть таблица -стандартизованный список свойств и есть еще 2 таблицы - в одной хранятся "типовые" значения, а в другой "индивидуальные". Далее происходит волшебный запрос, который формирует таблицу propertyName-value и делает PIVOT превращая таблицу в строку. Тут сопоставить то что есть в БД с вашей предметной областью под страхом смерти не получится. Получилось довольно путано, надеюсь коллеги поправят огрехи моих примеров.

Самый простой - dbFirst, Самый модный - CodeFirst. Самый удобный? Если честно, не знаю. У всех есть плюсы и минусы. От себя рекомендую dbFirst с маппингом на хранимые процедуры. Лучше не оставлять генерацию эффективных запросов на ORM, а учиться их писать самому.

Примерно вот-так

var temp = from t in A
                  join b in B on t.Site = b.Site AND t.C = b.C
                  where condition
                  select what you need

Использую подход DBFirst. Хранимки цепляются через - Update Model From DB -> select DB -> и в следующем диалоге последний пункт - "Stored Procedures And Functions". На всякий случай уточните версию EF и подход к разработке.

Создайте проект, в котором будете хранить наборы connectionString. Создайте проект в котором будет Entity и поставьте ссылку на стринги в другом проекте. Создайте Entity без добавления записей в конфиги(там есть галочка соответствующая), но сохранив куда-нибудь метаданные базы. Далее рядом с файлом Entity добавьте расширение через partial к классу контекста. В нем вам нужен метод Get без параметров, внутри него вы создаете EntityConnectionStringBuilder, в который из проекта с коннекшенами подсунете нужное соединение с базой данных, и метаданные, сохраненные заранее. Метод Get должен возвращать объект контекста, через ваш конструктор.
Примерно так

partial class MyContext{
public static MyContext Get()
{
var t = new EntityConnectionStringBuilder();
return new MyContext(t)
}
public MyContext(EntityConnectionStringBuilder ecsb):base(ecsb)
{

}

}