Вроде несложная бизнес-логика. А в чём проблема с состоянием задач? Их всего два, по сути: выполняется и выполнено. С каждым проверенным лайком у задачи сохраняется прогресс в бд. Когда прогресс равен 100%, то закрываем задачу.
DAL может знать о BLL, главное не наоборот. Сборку DAL не нужно давать друзьям :) DAL без бизнес логики не имеет смысла, потому что его цель - связывать бизнес логику с базой данных.
d-stream, соглашусь с ответом Александр Кузнецов. Каскадное удаление мы не можем отследить на уровне приложения.
spoiler
На ум вообще приходит один способ, но назвать его нормальным язык не поворачивается. Если мы используем EntityFramework в качестве ORM, то перед удалением можем пробежаться по всем таблицам DbContext'a, вычислить все FK, связанные с таблицей, из которой удаляется строка. Сделать по этим FK запросы, сохранить всю нужную инфу от связанных таблиц. Наконец, удалить строку. Если удаление прошло успешно, то пишем лог с ранее сохранённой инфой.
Соответственно, это делает практику каскадных удалений неприменимой к таблицам, требующих логирования.
Насчет "вредности" поля IsDeleted. Практика показывает, что лучше всего вообще не использовать в дизайне базы данных натуральные ключи (комбинации каких-то столбцов, их частей и т.д.), а использовать суррогатные (например, поле id с автоинкрементом). Используя натуральные ключи, какую цель мы преследуем? Зачастую это перекладывание бизнес-логики на уровень базы данных. В моём понимании бизнес-логика должна быть на уровне приложения. То есть мы не хотим добавлять новую строку, а потом отлавливать ошибку бд из-за того, что строка с таким ключом уже существует. Просто перед добавлением мы сами должны делать проверку и если в базе уже есть такая строка, то сообщить пользователю. Это часть нашей бизнес-логики.
Также уникальность (identity) строки с натуральным ключом может быть легко нарушена путем изменения одного из столбцов ключа. Это может быть проблемой в будущем. С айдишником такой проблемы не возникнет.
Таким образом, если мы отключаем каскадное удаление, используем натуральные ключи и у нас всё в порядке с бизнес-логикой, то поле IsDeleted хороший паттерн.
P.S. Мартин Фаулер в "Шаблонах" пишет о том, что нужно всегда избегать натуральных ключей.
Апдейт: забыл написать, что если есть желание мигрировать в другую страну, особенно по программам типа "Highly Qualified Workers", то диплом скорее всего понадобится :)
Вы действительно считаете, что кто-то кроме Вас лучше знает, что Вам выбрать? Я постарался дать оценку 1С с разных сторон, а уж расставлять приоритеты и решать - это Вы сами :)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
