Я имел ввиду, что с такой установкой пожарная не даст разрешение на работу клубу.
Уверен, все помнят печальные события в «Хромой Лошади» и что они были вызваны именно представлением с пиротехникой.
У меня есть несколько идеи для будущих статей на тему программирования, поэтому у меня большая просьба тем кто поставил минусы прокомментировать что именно не понравилось. Я надеюсь, ваша конструктивная критика поможет мне улучшить качество.
Спасибо!
Тот самый случай когда комментарии под постом не намного уступают по полезности самой статье :)
Мое гугление адекватного манула результатов не дало.
Добавьте пжл для истории линк на how to.
Спасибо.
Именно это и надо было, это было обязательно условие тех. задания.
Просто сам факт того что запись была изменена зачастую может быть не так полезен, как знание того кто именно это сделал, тем более в условиях достаточно большого коллектива.
А так конечно вы правы, навесить триггеры на таблицы в БД намного проще.
Небольшой комментарий на тему логирования каждого чиха.
Проект для которого был написан код использует примерно 150 сотрудников компании и именно тот факт что все логируется, уже несколько раз очень сильно выручал в разборках типа «Какой гад опять это переделал???», а также восстановить исходное состояние записи до редактирования не обращаясь к бэкапам и услугам разработчика/админа.
1. В принципе, разницы между тем как был вызван метод для логирования нет.
2. Вам ничего не мешает возвращать IQueryable
3. При отключенном трекинге у свойств объектов флаг IsModified не проставляется, а это нужно для того чтобы сохранять в историю только измененные свойства.
Соглашусь с первой частью вашего комментария, я действительно не упомянул название паттерна UnitOfWork, в остальном дело большей частью в дело в использованной терминологии.
По второй части вашего комментария:
Если я конечно вас правильно понял, то вы предлагаете отключить Entity Tracking у контекста и всем объектам, которые нужно сохранить вручную задавать их статус. Это действительно правильный и работающий механизм, но проблема в том, насколько я помню, в этом случае свойствам объектов не проставляются флаг «property.IsModified», а это необходимо для логирования.
Контекст базы данных наружу не отдается, отдается только его статические поле, которое хранит текущего пользователя, хотя конечно получить доступ к нему можно, пжл поправьте меня если я не прав.
Валидация объектов тесно связана с контекстом, поэтому я посчитал разумным реализовать валидацию в базовом классе репозитория.
Забавно, похожую технологию посадки разрабатывали еще в советском союзе, даже был где-то пост на хабре на эту тему.
Выпуск «Техника молодежи» 2003 год.
Похоже, вы не совсем внимательно прочитали. Фактически я написал GUI для FluentMigrator-a с рядом полезных фич вроде выполнения скриптов из папки.
Насчет EF CodeFirst Migrations см. мой коммент выше.
Совершенно верно, в случае использования EF Code First есть возможность использования стандартного механизма создания миграций, чем я с радостью пользуюсь в одном из проектов, но к сожалению даже в рамках использования EF, есть куча проектов которые используют подход Model First без возможности переписывания модели БД на Code First. Именно для таких проектов и существуют различного рода системы миграции.
На мой взгляд, это делается для того чтобы иметь возможность заблокировать, а в добавок еще и оштрафовать любого неугодного блогера, при этом заблокировав блог / сайт. Никаких подсчетов уникальных посетителей и прочего не будет.
Если конечно это все доберется до закона.
Уверен, все помнят печальные события в «Хромой Лошади» и что они были вызваны именно представлением с пиротехникой.
Спасибо!
Мое гугление адекватного манула результатов не дало.
Добавьте пжл для истории линк на how to.
Спасибо.
Просто сам факт того что запись была изменена зачастую может быть не так полезен, как знание того кто именно это сделал, тем более в условиях достаточно большого коллектива.
А так конечно вы правы, навесить триггеры на таблицы в БД намного проще.
Проект для которого был написан код использует примерно 150 сотрудников компании и именно тот факт что все логируется, уже несколько раз очень сильно выручал в разборках типа «Какой гад опять это переделал???», а также восстановить исходное состояние записи до редактирования не обращаясь к бэкапам и услугам разработчика/админа.
2. Вам ничего не мешает возвращать IQueryable
3. При отключенном трекинге у свойств объектов флаг IsModified не проставляется, а это нужно для того чтобы сохранять в историю только измененные свойства.
По второй части вашего комментария:
Если я конечно вас правильно понял, то вы предлагаете отключить Entity Tracking у контекста и всем объектам, которые нужно сохранить вручную задавать их статус. Это действительно правильный и работающий механизм, но проблема в том, насколько я помню, в этом случае свойствам объектов не проставляются флаг «property.IsModified», а это необходимо для логирования.
Валидация объектов тесно связана с контекстом, поэтому я посчитал разумным реализовать валидацию в базовом классе репозитория.
Выпуск «Техника молодежи» 2003 год.
Насчет EF CodeFirst Migrations см. мой коммент выше.
Если конечно это все доберется до закона.