Имхо, вероятность изменить алгоритм вычисления свойства и забыть вызвать PropertyChanged в нужном месте примерно равна вероятности забыть указать зависимость в менеджере зависимостей. Сложность обеих операций тоже примерно одинакова. Knockout Style Observables решает проблему необходимости указывания зависимостей (при условии, что в expression не встречаются вызовы кастомных методов). Не знаю, может он и не умеет обрабатывать вложенные коллекции, но его этому можно научить — достаточно отслеживать в дереве выражений вызов методов-расширений над IEnumerable.
А какую проблему решает ваш проект? Незначительно увеличивает cohesion? Вы думаете, что незначительное увеличение cohesion окупает усложнение кода путём добавления нового проекта? Вижу, что проделано много работы, но пока что не понимаю, для чего.
Не совсем понимаю, зачем городить огород, почему нельзя сделать что-то наподобие:
public void RegisterPropertiesDependencies(string propertyName, List<string> dependenciesProperties)
{
foreach (var dependencyProperty in dependenciesProperties)
{
this.PropertyChanged += (sender, args) =>
{
if (args.PropertyName == dependencyProperty) RaisePropertyChanged(propertyName);
};
}
}
...
RegisterPropertiesDependencies("FullName", new List<string> { "FirstName", "LastNameName"});
Для коллекций вложенных объектов пробегать в цикле по их PropertyChanged (для этого использовать какой-нибудь ObservableCollection, чтобы отследить добавление нового объекта и подписаться на его PropertyChanged).
Да, но их можно решить. Можно менять дерево выражений внутри как угодно. Нельзя наружу вернуть null, если возвращаемое значение присваивается not nullable полю, но это и не нужно: при такой попытке ORM кидает исключение; следовательно, должен кинуть исключение и unit-тест.
Подход похожий: модификация дерева выражений перед его выполнением.
Кстати, у вас для предотвращения NulLReferenceException возвращается не null, а default(TResult) (в методе With). Из-за этого в будущем могут быть проблемы, если вы решите обрабатывать ситуацию сравнения null == null.
Это ещё одна демонстрация концептуального разрыва. Для запроса к бд такая запись корректна, а в юнит-тесте выбросится исключение, если doorHandle == null.
Как вариант, если будет высокая нагрузка, можно специально для Users_online завести отдельную базу данных на отдельном сервере и настроить репликацию в неё таблички Users из основной базы. Но это нужно по ситуации смотреть, что и как лучше оптимизировать.
Кстати, а директор до 12 сидел и отлаживал код, потому что сотрудник ошибку на продакшен занёс, или потому что в срок не уложился? В статье это не указано. Наверное, автор считает, что это неважно. Неважно, что за ситуация, почему она возникла, как на неё нужно реагировать, как не допустить подобного в будущем; важно — что начальник недоволен, а значит пришло время для человеческих жертвоприношений унижений. Странноватая статья для управленцев садистов на портале для программистов.
Я возможно сейчас выскажу непопулярную точку зрения, но, если руководитель сидит в 12 часов ночи и отлаживает код за сотрудника, который после окончания своего рабочего дня ушел домой, наказывать тут нужно только одного человека — руководителя.
А ещё неплохо иметь тестовую инфраструктуру и реальную, а не делать всё сразу на реальной… В любой неприятной ситуации надо первым делом подумать, как избежать подобной ситуации в будущем. В данном случае — завести тестовое окружение. Если решение найдено, то можно никого и не наказывать за невнимательность или неудачливость — проблема уже исправлена и по той же самой причине не повториться. А искать виноватых в любой неприятной ситуации до или вместо поиска и устранения проблемы, коренной причины неприятной ситуации, — не самый позитивный подход.
А вообще — почему эта статья не на мегамозге?! Специально же отдельный ресурс создали, чтобы честным программистам не отвлекаться на статьи управленцев-недоучек!
Я подразумевал Repository, когда работа с данными из бд идёт почти так же, как если бы они были массивами в оперативной памяти.
Ну а вообще ActiveRecord может быть выстроена поверх простой Mini-ORM наподобие Dapper-а, тогда Dapper будет непосредственно маппить, а ActiveRecord будет слоем доступа к данным, который будет скармливать sql-ные запросы непосредственно ORM. Ну а вообще я пожалуй пропущу этот назревающий холивар по поводу терминологии.
Можно написать класс-джойнер. Первый сервис — СписокДрузей — содержит запрос как получать список друзей, СписокОнлайн содержит запрос как получить список пользователей онлайн: «select * from UsersOnline u {0} where u.status = 'online'». Вместо "{0}" может быть пустая строка или подстрока для джойна «join ({0}) something on u.user_id = something.user_id». И запрос и подстрока хранятся в СписокОнлайн. Ну и нужно учесть что where тут должен быть только один. Джойнер должен понимать как сджойнить данные двух сервисов: либо сгенерит на основании двух сервисов sql с джойном, или, если данные одного сервиса в кэше а другого в базе, то возьмёт айдишки из кэша и подставит их в запрос. Но предупрежу: генерация sql путём конкатенации строк — скользкая дорожка, часто чреватая труднообнаруживаемыми ошибками.
Если в приложении не нужно джойнить таблицы пачками, то проще и надежнее будет просто сделать два запроса вместо одного, отфильтровав вторым сервисом результаты первого.
Можно просто захардкодить sql запрос со всеми джойнами, а не вычислять его динамически, но тут возникают проблемы с гибкостью и дублированием знания.
Ну а ещё лучше — переписать слой доступа к данным и не использовать ActiveRecord, но самый лучший путь не всегда самый верный :), т.к. есть ещё сроки, бюджет, возможно жёсткие требования по быстродействию.
Я бы лично сделал так: если проблема единичная, то отфильтровал бы вторым сервисом результаты первого. Если проблема повсеместная — избавился бы от ActiveRecord и использовал бы ORM. Удачи
Согласен, идея автоматизации + БОД привлекательна. Количество магазинов и управленцев зашкаливает. Сомневаюсь, что они нужны в таком количестве. Но это рабочие места. Для развития человечества более позитивно было бы потратить этот человеческий ресурс на развитие науки. Но тут вопрос скорее культуры, нежели экономических возможностей.
Да, можно дать человеку базовый доход, но где гарантия, что он начнёт заниматься наукой\искусством\чем-то социально-полезным, а не начнёт набирать лишний вес, сидя у телевизора?
Да, можно заменить кассиров на свободные кассовые аппараты, чтобы покупатели сами пробивали товар (как уже сделано в некоторых европейских странах), но где гарантия, что товар не растащат «нахаляву»?
Но вообще, ИМХО, за БОД — будущее. Но внедрить его в один день врятли получится. Тут нужно не петиции писать, а автоматизировать всё что можно заавтоматизировать. Ну и пособия по безработице понемногу увеличивать.
В википедии забанили? ВВП — это совокупная рыночная стоимость всех конечных товаров и услуг, произведенных в экономике (внутри страны) в течение одного года. То есть, чем больше товаров\услуг произвели, тем больше ВВП.
И не говорите, ох уж эта белковая жизнь! Давно пора мутантов из пробирки засылать на Венеру серной кислотой дышать. Ну или терминатора запилить. А то эволюционно сложившаяся практика не выдерживает никакой критики.
А если серьёзно — на данный момент у нас нет ничего лучше, и неизвестно когда появится. Нужно уметь работать с тем что есть.
По-моему, связь объясняется достаточно просто. Чтобы обеспечить такую же вовлечённость женщин в формирование ВВП, как и у мужчин, автор предлагает заставить женщин работать в таком же объёме и на тех же профессиях, что и мужчины. Для работы женщин в брутальных мужских профессиях, придётся накачивать их тестостероном. Чтобы у женщин не снижалась продуктивность во время беременности, придётся выращивать детей в пробирках (а мы на данный момент не умеем делать это качественно). Чтобы женщины не уходили в декрет по уходу за ребёнком, нужно ухаживать за детьми в специальных учреждениях (а о качестве детских садов мы все давно наслышаны). Всё это не может не повлиять на здоровье детей.
А вообще, разрушать семейный очаг ради 8-20% ВВП — это мелочно. Инновации в производстве, освоение космоса и дна океана — вот достойные цели.
А то что предлагает автор — это просто утопия. Большинство людей живёт ради того, чтобы приобрести побольше накоплений (знания, сила, власть, деньги) и передать их потомкам. Потомок тут рассматривается как некая реинкарнация: у него схожие гены и, благодаря воспитанию, мышление. Люди не дадут отобрать их смысл существования, так что можно не переживать — утопия останется утопией. По крайней мере пока общество не сможет решать те задачи, которые решают женщины, «недоприносящие» 8% ВВП. Как это сделать — автор умалчивает. Да и не факт, что на это уйдёт меньше денег, чем эти самые 8% ВВП.
А какую проблему решает ваш проект? Незначительно увеличивает cohesion? Вы думаете, что незначительное увеличение cohesion окупает усложнение кода путём добавления нового проекта? Вижу, что проделано много работы, но пока что не понимаю, для чего.
Для коллекций вложенных объектов пробегать в цикле по их PropertyChanged (для этого использовать какой-нибудь ObservableCollection, чтобы отследить добавление нового объекта и подписаться на его PropertyChanged).
Кстати, у вас для предотвращения NulLReferenceException возвращается не null, а default(TResult) (в методе With). Из-за этого в будущем могут быть проблемы, если вы решите обрабатывать ситуацию сравнения null == null.
Это ещё одна демонстрация концептуального разрыва. Для запроса к бд такая запись корректна, а в юнит-тесте выбросится исключение, если doorHandle == null.
Нашёл на сайте этой самой Сибирикс: То, что другие будут делать три месяца, мы сделаем за один.
жертвоприношенийунижений. Странноватая статья дляуправленцевсадистов на портале для программистов.А ещё неплохо иметь тестовую инфраструктуру и реальную, а не делать всё сразу на реальной… В любой неприятной ситуации надо первым делом подумать, как избежать подобной ситуации в будущем. В данном случае — завести тестовое окружение. Если решение найдено, то можно никого и не наказывать за невнимательность или неудачливость — проблема уже исправлена и по той же самой причине не повториться. А искать виноватых в любой неприятной ситуации до или вместо поиска и устранения проблемы, коренной причины неприятной ситуации, — не самый позитивный подход.
А вообще — почему эта статья не на мегамозге?! Специально же отдельный ресурс создали, чтобы честным программистам не отвлекаться на статьи управленцев-недоучек!
Ну а вообще ActiveRecord может быть выстроена поверх простой Mini-ORM наподобие Dapper-а, тогда Dapper будет непосредственно маппить, а ActiveRecord будет слоем доступа к данным, который будет скармливать sql-ные запросы непосредственно ORM. Ну а вообще я пожалуй пропущу этот назревающий холивар по поводу терминологии.
Если в приложении не нужно джойнить таблицы пачками, то проще и надежнее будет просто сделать два запроса вместо одного, отфильтровав вторым сервисом результаты первого.
Можно просто захардкодить sql запрос со всеми джойнами, а не вычислять его динамически, но тут возникают проблемы с гибкостью и дублированием знания.
Ну а ещё лучше — переписать слой доступа к данным и не использовать ActiveRecord, но самый лучший путь не всегда самый верный :), т.к. есть ещё сроки, бюджет, возможно жёсткие требования по быстродействию.
Я бы лично сделал так: если проблема единичная, то отфильтровал бы вторым сервисом результаты первого. Если проблема повсеместная — избавился бы от ActiveRecord и использовал бы ORM. Удачи
Да, можно дать человеку базовый доход, но где гарантия, что он начнёт заниматься наукой\искусством\чем-то социально-полезным, а не начнёт набирать лишний вес, сидя у телевизора?
Да, можно заменить кассиров на свободные кассовые аппараты, чтобы покупатели сами пробивали товар (как уже сделано в некоторых европейских странах), но где гарантия, что товар не растащат «нахаляву»?
Но вообще, ИМХО, за БОД — будущее. Но внедрить его в один день врятли получится. Тут нужно не петиции писать, а автоматизировать всё что можно заавтоматизировать. Ну и пособия по безработице понемногу увеличивать.
А если серьёзно — на данный момент у нас нет ничего лучше, и неизвестно когда появится. Нужно уметь работать с тем что есть.
А вообще, разрушать семейный очаг ради 8-20% ВВП — это мелочно. Инновации в производстве, освоение космоса и дна океана — вот достойные цели.
А то что предлагает автор — это просто утопия. Большинство людей живёт ради того, чтобы приобрести побольше накоплений (знания, сила, власть, деньги) и передать их потомкам. Потомок тут рассматривается как некая реинкарнация: у него схожие гены и, благодаря воспитанию, мышление. Люди не дадут отобрать их смысл существования, так что можно не переживать — утопия останется утопией. По крайней мере пока общество не сможет решать те задачи, которые решают женщины, «недоприносящие» 8% ВВП. Как это сделать — автор умалчивает. Да и не факт, что на это уйдёт меньше денег, чем эти самые 8% ВВП.