Валерий Абакумов

Коллеги, в принципе, можно отнести это к решению вопроса - в Visual Studio при публикации ASP.NET приложения в настройках Publish'а есть такая опция - "Precompile during publish". При конфигурировании этой опции снимается галочка с "Allow precompiled site to be updatable" + можно поиграться с блоком "Merge option". Эта галочка способствует тому, что все View при публикации будут преобразованы в *.dll файлы, а блок "Merge option", насколько я понял, позволяет настроить различные способы этого преобразования View -> dll. Решение пока отмечать не буду - хотелось бы услышать еще варианты и "поиграться" с этими настройками публикации.

Добрый день!

Хотелось бы добавить про контексты EF: stackoverflow.com/questions/9415955/c-sharp-workin...

Поясню: когда я впервые столкнулся с масштабным применением EF, в том проекте использовался класс, в котором в виде поля объявлялся контекст. Т.е. контекст EF существовал все время, пока существовал этот класс (DataService). Так вот: все было хорошо до тех пор, пока не пришлось заняться ускорением работы приложения. И обнаружилось, что такой подход практически не позволяет использовать библиотеку TPL (Task Parallel Library), т.к. постоянно возникали ошибки, связанные с тем, что "контекст уже открыт". Ни в коем случае не используйте контекст EF по паттерну "Одиночка" и в статическом классе - наберетесь больших проблем и замучаетесь исправлять ошибки. Исходя из своего опыта (а также опыта моих коллег и друзей), пока что самым удачным применением EF является (как и написано в статье) использование контекста с коротким жизненным циклом, т.е. написали метод (который, например, получает список городов из БД и который, соответственно, будет внутри слоя доступа к данным), внутри инициализируем контекст (лучше с помощью using), получаем данные, оборачиваем их в модель (если надо), закрываем контекст и возвращаем данные наверх.

P.S. Хотелось бы также порекомендовать Вам НЕ работать с классами, генерируемыми EF, в слое бизнес-логики, а писать для этих классов обертки (модели). В одном из проектов, которыми я занимался, используется WPF + MVVM + IoC (Unity Container), и в нем же весь интерфейс биндится к классам EF... Поверьте, это ужасно. Лучше сразу проектируйте так, чтобы классы EF у Вас использовались только внутри слоя доступа к данным, а наверху (в бизнес логике) вся работа ведется с классами-обертками над классами EF (т.е. чтобы классы слоя бизнес-логики ничего не знали о классах EF). В этом еще и такой плюс, что если Вы по каким-либо причинам решите отказаться от EF и перейти, например, на NHibernate или Native Sql, то все изменения коснутся только слоя доступа к данным.

В итоге с другом нашли альтернативное решение.
Написали консольное приложение, которое берет последние курсы валют с сервиса ЦБ РФ и вызывает хранимую процедуру из БД, которая принимает табличный тип и обновляет курсы валют в БД. В текущей используемой панели управления хостингом имеется инструмент "планировщик задач" (в-общем, планировщик Windows). В настройках указали путь к консольному приложению, выставили периодический запуск этого приложения 1 раз в сутки - и вуаля! Задача решена.

И тем не менее, спасибо всем за ответы.

Добрый день!

Возможно, вопрос еще актуален, поэтому отвечу.
Для передачи параметра в метод действия Вам необходимо, чтобы сам метод действия принимал этот параметр (как правильно указал chydaya):

public ActionResult Dialog(string dataDialogId)
{
	//...
	return View();
}

Прописывать значения параметров в маршруте вовсе необязательно. Т.е. маршрут может быть стандартным:

routes.MapRoute(
	name: "Default",
	url: "{controller}/{action}",
	defaults: new { controller = "Home", action = "Index" }
);

Если Вы для разработки используете Visual Studio, то при вводе "Html.ActionLink(" у Вас сразу срабатывает IntelliSense, которая подсказывает, какие входные параметры есть у этого метода. И если внимательно присмотреться, то, как верно заметил Vadimyan, у него есть различные перегрузки, и в некоторых есть параметр object routeValues - это то, что Вам нужно. Именно в этом параметре Вы указываете переменные для метода действия, например, так:

@Html.ActionLink("Вход", "Dialog", new { dataDialogId = "entry" })

В Вашем примере, который Вы указали в вопросе:

@Html.ActionLink("Вход", "Dialog", null,

                               new
                               {
                                   @class = "openDialog",
                                   data_dialog_id = "entry",
                                   data_dialog_title = "Вход",
                                   data_dialog_width = "auto",
                                   data_dialog_height = "auto"
                               })

Вы задаете html-атрибуты, а в качестве переменных маршрута у Вас стоит null. Сгенерированная html-разметка у Вас будет иметь следующий вид:

<a href="/{какой-то контроллер}/Dialog" class="openDialog" data_dialog_id = "entry" data_dialog_title = "Вход" data_dialog_width = "auto" data_dialog_height = "auto">Вход</a>

Общая рекомендация
Потратьте время, чтобы от и до изучить MVC по книге "ASP.NET MVC3 Framework с примерами на C# для профессионалов". Это фундамент, и даже на asp.net Вы не найдете настолько подробной информации о том, как работает и как правильно работать с ASP.NET MVC. Я пользовался туториалами (еще по WebForms + EntityFramework) с сайта asp.net, но они направлены на то, чтобы "прочитал туториал и начал делать". Однако если Вы хотите грамотно разрабатывать на ASP.NET MVC, начните с изучения основ и фундамента.

Надеюсь, я Вам немного помог.
Успехов!