Николай Мохов

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

Лучше вернуть пустой список. Бизнес-логика как правило проверяет коллекцию на наличие хоть каких-то элементов(Count/Length>0) или по признаку (Where().Count/Length>0). Возврат NULL предварит эти проверки доп. проверкой на NULL. Лично вы из каких соображений хотите вернуть NULL?
UPD: Есть альтернатива - постоянно ловить NullReferenceException, но с тем же успехом можете использовать оператор goto.

Делегаты - это форма существования функтора на платформе .NET. Почитайте про функтор, и поймете (наверное), зачем нужен делегат.

Если коротко и грубо - вызвать напрямую можно всегда только конкретный метод, который будет четко известен еще на стадии компиляции. Если же вы пишете некий обобщенный алгоритм и заранее не знаете, какие КОНКРЕТНО методы у каких КОНКРЕТНО объектов будете вызывать - вам необходимо будет воспользоваться делегатом.
Простейший пример - LINQ-методы. Метод фильтрации Where получает своим параметром функтор, который возвращает true или false, что значит - оставить элемент в коллекции или выкинуть его. В этом методе в цикле foreach вызывается переданный делегат для каждого элемента. Where понятия не имеет, какой конкретно метод (или лямбда-выражение) вы захотите подставить в качестве фильтрующего предиката.

Другой пример - события. События в дотнете - это делегаты с урезанным публичным интерфейсом. Так как, к примеру, кнопка не знает о том, кто захочет подписаться на событие ее нажатия, она никак не может вызвать конкретные методы у конкретных объектов. Чтобы иметь возможность сообщать о своем нажатии, кнопка выставляет событие Click наружу, давая возможность записать туда конкретные методы для вызова.

Кстати, делегат выполняет еще и функцию связывания: для нестатических методов делегат хранит еще и объект, для которого будет вызван instance-метод (т.е. связывает пару объект-метод).

Таким образом,
> Почему методы нельзя передавать в функции без делегатов?
Делегаты - это и есть передача методов в функции.

Основное отличие между ссылочными и значимыми типами в том, что одни передаются по ссылке, а другие по значению, как бы это банально не звучало. Расположение в куче или на стеке — это всего лишь следствие особенностей работы с объектом, например, времени жизни, стратегией копирования, размером.

Также стоит понимать, что CLR не всегда располагает вещественные объекты на стеке. Вот статья на эту тему от Эрика Липперта.

Родной контент тоже должен отдаваться по https, а в коде видно например:

mg class="lcomm-user-foto" src="http://prosmart.by/uploads/fotos/foto_1.gif" alt="li4nost-фото">

Плюс соединение с гуглом тоже по http
Все ссылки переводите на относительные, т.к. сейчас принудительно прописан http

Вы имеете ввиду разбить проект на несколько файлов?
Вам понадобится создать по два файла для каждого модуля: заголовочный (с объявлениями) и собственно файл с реализацией (определением). Файлы с объявлениями имеют расширение .h .H .hpp и так далее.

main.cpp: определение функции main.

// Следующая строка при компиляции будет заменена на содержимое файла helloworld.h
#include "helloworld.h"

int main(int argc, char** argv)
{
    helloworld(); // Вызываем функцию определённую в другом файле.
    return 0;
}

helloworld.h: объявление функции helloworld

// Следующая конструкция называется include guard.
// Благодаря ней вы не сможете вставить содержимое этого файла дважды,
// что поможет вам избежать ошибок переопределения.
#ifndef HELLOWORLD_H 
#define HELLOWORLD_H

// Объявление функции.
// Если функция объявлена но не определена в данном файле,
// компилятор будет искать её реализацию в других файлах.
void helloworld();

#endif

helloworld.cpp

// Снова вставляем содержимое файла helloworld.h
#include "helloworld.h"

#include <iostream>

// Определяем функцию.
void helloworld()
{
    std::cout << "Hello, world!";
}

metanit.com/sharp/mvc5/index.php
Очень годный ресурс.

есть asp.net/mvc

Конечно, по своей природе ORM призваны помочь держать всю бизнес-логику в самом приложении, а не в базе данных. В целом, этот подход лучше масштабируется, и, в придачу, позволяет меньшими усилиями сменить СУБД в случае сильного изменения требований к проекту.
Однако есть ряд задач, где триггеры вполне могут работать в паре с ORM-библиотекой. Это как раз таки НЕ бизнес-логика, а скорее support-логика. Сходу могу вспомнить следующее:
- поддержка целостности денормализованных данных - пересчет в триггере "избыточных" значений, например сумм, средних и т.д. (т.е. таких, которые всегда можно посчитать и которые хранят исключительно для повышения производительности запросов). В этом случае даже если кто-то захочет поработать с БД не пользуясь O/R маппингом (например, выполнить пару выборок для аналитики), не произойдет рассогласования данных;
- поддержка хронологических и аудит-таблиц; это также логика, в общем-то не зависящая от предметной области, и зачастую она НЕ мапается в ORM-ке (особенно в случае аудит-таблиц - если с историей приложение еще может работать, то аудит как правило нужен лишь в исключительных случаях - повреждение данных, проблемы с безопасностью БД и т.д. - и запросы к таким таблицам делаются вручную в ходе исследования проблемы).
В EF с помощью этого атрибута вы можете указывать, что значение свойства сущности генерируется самой БД и EF не должна участвовать в его обновлении.

никак не хранить, предоставьте эквайринг банкам.
исходя из того что вы задаёте такой вопрос - эти данные у вас гарантированно украдут.

@helper SomeNameMethod(SomeClass object)
{
//Some RazorMarkup
}
//вызывать @SomeNameMethod(object)

Попробуй так
UPD: Ну или действительно сделать PartialView для ваших коллекций.

Вы исходите в своем вопросе из не очень верного предположения о том, что можно быть профессионалом только в какой-то одной технологии, но это не совсем так. Чем больше языков, парадигм и технологий Вы знаете, тем обширнее Ваш кругозор, и тем больше набор инструментов и шаблонов, которые Вы сможете применять в повседневной практике.
Думаю, я ответил на Ваш вопрос. :)