Проблема в том, что загрузчик не найден. У вас UEFI или BIOS? Проверяйте в настройках в каком режиме загружается система и учитывайте желаемое при установке, в момент разбивки диска на разделы.
Читайте ввод, заполняйте объекты нужными типами. У встроеных типов есть методы наподобие int.Parse(string) и int.TryParse(string), они вам в этом помогут.
Matsun:
1 - верно
2 - верно и в сервис (в конструктор) нужно инжектить репозиторий. IoC-контейнер автоматически подтянет все необходимые зависимости зависимостей.
3 - Domain (который BL) не должен ни от кого зависеть, это такая рафинированная бизнес-логика в вакууме.
4 - верно
Конечно, это пока размахивание руками в воздухе. Если сделаете проект, зальете на какой-нибудь гитхаб/битбакет, смогу поревьюить и может дельное подсказать.
Matsun: то есть что-то вроде GetProductsByCategory лучше оставить в репозитории, а GetProductPricesWithDiscount (получить продукты с учетом скидки, т.е. модификация сущностей из базы каким-то бизнес-правилом - скидкой) лучше убрать в сервис, где сначала из репозитория вытащить интересующие продукты, затем получить скидку для пользователя, применить ее к этим продуктам...
> метод, который модифицирует текст статьи CreateTable, я бы мог поместить в класс "BlogPostRepository", который находится в DAL
Если таблица постоянная, метод предполагается вызывать один раз (при деплое приложения на сервер) и вы используете EF Code First, то лучше бы его и заюзать. Нужно как-то заранее продумать, как вы будете мигрировать данные при изменении структуры БД. Можно использовать миграции EF, но лучше бы с этим заранее познакомиться. Хотя можно и руками писать update-скрипты, тогда вся эта кухня будет у вас под контролем.
> не правильнее ли будет такие специфичные методы обработки перенести с Business logic?
Верно, вы это хорошо заметили, бизнес-логика должна находиться в BL. Для какой-то специфической обработки данных нужно создавать сервис (BlogPostServeice или как-нибудь так) в BL, в который инжектися репозиторий (через интерфейс, само собой), как источник данных, и уже этот сервис прокидывать в ASP.NET-контроллер. Сервис представляет собой некоторый логический модуль в терминах нашей прикладной области, поэтому он может использовать несколько репозиториев.
Сложный момент здесь вот в чем: как понять, поместить какую-то логику в репозиторий (DAL) или в сервис (BL)? Тут решается так: репозиторий должен быть максимально глупым, его задача - генерить SQL (или общаться с DbContext, в случае EF). Если мы хотим делать какие-то хитрые вычисления на стороне БД, то делаем специальный метод в репозитории (вызов к нему из контроллера можно просто прокинуть через сервис). Если же мы просто выкачиваем данные, а потом делаем с ними какие-то бизнес-преобразования, то их лучше унести в сервис.
Где делать логику: в базе или в приложении - это зависит от кучи факторов (использование ресурсов конкретным запросом, удаленность сервера с БД от сервера с приложением и прочее), решать нужно на месте.
Сначала читаете про работу с файлами в бинарном режиме в вашем языке. Потом читаете спецификацию интересующего формата. Но учите, что форматы могут достаточно неплохо отличаться (особенно использующие сжатие), а сами бинарные файлы иметь свои приколы от системы к системе (big/little endian, выравнивание и т.п.). В качестве некой прослойки можно взять какой-нибудь OpenCV.
Скроллиться вниз, ждать, пока пройдут все аяксовые запросы. Так до тех пор, пока не появится признак, что больше запросов не будет (от сайта зависит, допустим, просто перестанут добавляться новые значения).
Matsun: Ах, да, у Фримана же репозитории IQuerable возвращают) Это неправильно.
> т е тут и может быть размещён запрос на извлечение записи из БД?
Нет. Вы не знаете, какой ORM (например, EF) будете пользоваться завтра. Какой СУБД. Или вообще откуда брать данные. Может будет другой микросервис или Elastic Search. Поэтому хорошо было бы изолировать конкретный способ доступа к данным в DAL, создав абстракцию в виде IRepository.
> Т е это и есть модели представления?
Да.
> А в эту модель я могу запихнуть свой метод - CreateTable
Нет, ее задача - донести данные до представления. Откуда они берутся и как хранятся - это уже задача контроллера позвать некий сервис из BL, который позовет репозиторий из DAL, который уже знает, нужно ли ему создавать таблицу или, скажем, файл.
Как говорится, меньше знаешь - крепче спишь =) Изолируя слои между собой, вы уберегаете себя от "эффекта бабочки", где маленькое изменение в одной части кода рушило бы все к черту на другом конце. И протестировать вам достаточно этот маленький кусочек, а не всю программу во всех возможных режимах, снова и снова.
Виталий: Qt с некоторых пор умеет в LGPL (что позволяет использовать его даже в коммерческих продуктах), а Unity вроде бы условно бесплатный для инди (обязательный сплэш-скрин в начале или что-то вроде).
Ariox41: Так и эти достаточно сомнительны, ибо это время несоизмеримо меньше собственно разработки и измеряется в минутах, особенно учитывая, что сейчас можно выборочно устанавливать компоненты.
