Maa-Kut

Поскольку речь идет именно о структурах, второй вариант не имеет смысла, т.к. из словаря все равно будут возвращаться копии сохраненных в словаре структур: в C# структуры - это value type.

Ну и на будущее: если уж идти вторым путем, то надо активнее использовать инкапсуляцию. Т.е. инициализацию поля spravochnik и получение значения из него надо выполнять непосредственно в классе pogreb. Наружу класс должен выставить не публичное поле (публичные поля - почти всегда зло), а метод или свойство, которые будут проверять/инициализировать sparovochnik и искать в нем значение.

Список баз данных можно получить из sysdatabases:
SELECT [name] FROM master.dbo.sysdatabases;

Список таблиц - ну, скажем, из sys.tables:
SELECT [name] FROM sys.tables;

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

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

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

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

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

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

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

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

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

Судя по всему, речь в обоих случаях идет о multicast delegates; таким образом, да, одно и то же. Хотя, конечно, было бы интересно взглянуть на код, чтобы точнее понять, что именно подразумевал автор каждого из терминов.

Как насчет того, чтобы ридеры в using забрать?

using(NpgsqlDataReader drGetDBTables = commandGetDBTables.ExecuteReader())
{
        //tr.Commit();
        while (drGetDBTables.Read())
        {
            existsInDBTables.Add(drGetDBTables[0].ToString());
        }
}
...
using(NpgsqlDataReader dr = command.ExecuteReader())
{
            while (dr.Read())
            {
               // UserData ud = new UserData();
                ud.id = Int32.Parse(dr[0].ToString());
                ud.guid = (dr[1].ToString());
                ud.name = (dr[2].ToString());
                ud.userblob = (byte[])dr[3];
                uds.Add(ud);
                //File.WriteAllBytes("outputimg.jpg", ud.userblob);
                //Console.ReadKey();

            }
}

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