Сергей Коновалов

1) учим C# + алгоритмизацию (вы как минимум должны знать что происходит при вставке в хэш-таблицу и хотя бы примерно понимать что такое куча, на бэкэнде структуры данных знать очень полезно)
2) учим ООП (читаем паралельно Фаулеров, Кентов Бэков, Бобов Мартинов)
3) постепенно берем ASP MVC и вперед к свершениям.
4) асинхронное/паралельное программирование

Каждый пункт сдобрим практикой

При наследовании сначала создаются методы базового типа, а потом дополняются методами наследника. Вы инстанциируете класс GrandFather, что, кстати, странно. Отсюда получается два варианта:

GrandFather gf = new GrandSon();
            Console.WriteLine(((GrandSon) gf).GetDescription());

либо

GrandSon gf = new GrandSon();
            Console.WriteLine(gf.GetDescription());

Надо сделать Fetch для адресов в закупках, либо сконфигурировать маппинг так, что бы эта связь не была lazy load. Такой поведение - особенность Entity Framework'a, и оно настраивается. Почитай документацию.

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

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

ORM-ку сверху накиньте, вместо прямого ADO.Net, и будет вам современные технологии. В тренде, очевидно, Entity Framework, хотя NHibernate - нестареющая классика.
Можете заморочиться над архитектурой, вплоть до разделения на клиент и сервер - тогда будет место и для Web API.
Или другой вариант - подтащить документую БД, хотя для бухгалтерии не факт что это хорошее решение (разве что в пару к реляционной, для хранения характеристик ваших товаров).