Если цель хранить их в разных не связанных таблицах БД, согласен.
Но так будет очень неудобно работать со всеми элементами в целом.
Например, мы не сможем получить экземпляр IData только по id, без указания его типа, использовать всю мощь полиморфизма и т.д.
Не лучше ли сделать один Dictionary<int, IData>, а базе данных разнести информацию по таблицам следующим образом:
В «основной» таблице например BaseItems хранить автоинкрементный id и поля общие для всех типов IData.
Для каждого типа IData создать таблицу, которая будет хранить только поля специфичные для данного типа и id. И по id связать все эти таблицы с BaseItems.
Спасибо за статью! Когда почти дочитал очень хотелось написать в коменте: Почему не сделать возможность задания прав как для конкретных пользователей так и для ролей. Но Вы все же это в принципе учли в самом конце статьи ))
В том-то и дело, что вариант автора статьи — это не паттерн.
Паттерн или не паттерн, или реализация паттерна это вопрос скорее философский и/или риторический.
Проще говоря, вариант автора статьи предпочтителен тогда и только тогда, когда кто-то зачем-то хочет заэнфорсить правило «строго один Dispose», причем из-за архитектурных соображений (потому что практической разницы нет).
Полностью согласен. Но для чего и зачем это в принципе может быть нужно?
А я разве утверждал обратное? В том то собственно и вопрос, что мы по сути пытаемся оптимизировать количество вызовов методов которые по сути ничего не делают и сразу вызывают return.
Какой именно?
Вариант автора статьи. Я ведь очень подробно изложил свои выводы.
Насчет скорости освобождения ресурсов, я пожалуй не корректно сформулировал. Думаю можно считать этим суммарное время вызовов всех Dispose или количество вызовов Dispose. Но это не важно, вырывание этого куска из моего поста выше для отдельного обсуждения, я считаю, крайне не корректным.
Для меня важно лишь определиться имеет ли смысл использовать данный паттерн.
В общих случаях, я думаю всем очевидно, что нет. Т.к. страдает простота, красота, читабельность и т.д. кода, увеличивается объем инфраструктурного кода, может возникнуть куча проблем с проектированием и рефакторингом из ничего и т.д. И в итоге можно получить проектирование ради проектирования…
Как я писал выше возможно это может иметь смысл в каких-то частных случаях, как вариант оптимизации, но лично я не вижу каких-то явных плюсов в том, что ВОЗМОЖНО сократится количество вызовов Dispose такой ценой.
Я просто не могу представить задачу или ситуацию когда использование этого паттерна в контексте .NET будет оправдано. Автор в статье упоминал про граф объектов… В частном случае, если классы этих объектов описывают относительно примитивные сущности, целесообразным будет использование структур, а не классов со всеми вытекающими плюсами типов значений над ссылочными и это даст ощутимую оптимизацию быстродействия и использования памяти, если выделять память сразу для больших групп таких объектов.
Возможно не совсем верная аналогия, но это можно сравнить с авто с АКПП и МКПП. И использование этого паттерна это попытка ехать на АКПП как на МКПП. Но если критичны возможности МКПП, не лучше ли изначально выбрать МКПП.
Ведь основные преимущества C# это скорость разработки и высокая сложность отстрелить себе ноги, а в данном случае мы получается пытаемся идти против этих основных концепций.
Опять же, буду рад объективной критике и примеру того когда этот паттерн даст ощутимые плюсы от своего использования.
Что именно почему? Все ведь расписано в моем посте. Если в каком-то проекте критична скорость освобождения ресурсов, то вариант автора оказывается более предпочтителен (в теории). А на практике, я считаю, реальной пользы от этого не будет, т.к. сборщик мусора приезжает когда захочет и прироста производительности от освобождения ресурсов в «правильном» порядке без дублирования не будет заметно.
Думаю, что называть это некомпетентностью все же не верно. Ведь освобождение ресурсов в «правильном» порядке без повторов по сути ничего не дает. А отсутствие необходимости думать об этом дает довольно много. В 1-ую очередь повышает скорость разработки и надежность.
Насколько я понял, основная цель этих эксепшенов построить приложение в котором не будет повторных Dispose. Но я так и не решил для себя однозначно, имеет ли это смысл.
Хотел еще добавить. Вряд ли мне придется применить на практике знания полученные из этой статьи и ее обсуждения в ближайшее время, но все это очень познавательно и для себя я пришел к выводу, что оба варианта имеют права на жизнь.
Если делать API для узкого круга лиц и/или для проекта в котором критична скорость освобождения ресурсов, то вариант автора намного более предпочтителен.
Если же делать API «для всех», то однозначно только вариант допускающий множественные Dispose, т.к. это уже давно устоявшаяся практика для «всех» и в 1-ую все должно быть надежно и интуитивно понятно.
Но с другой стороны C# ведь в принципе не предназначен для систем реального времени и возможно концепция автора просто не имеет смысла, а в случаях когда критична скорость освобождения ресурсов следует изначально выбирать C++ и т.п. и полностью контролировать ситуацию. Буду рад объективной критике.
Отличная статья. Паттерны проектирования очень хороши в теории, а на практике довольно часто просто рыдаешь когда их очень грамотно к месту применяют 'гуру' проектирования.
Но так будет очень неудобно работать со всеми элементами в целом.
Например, мы не сможем получить экземпляр IData только по id, без указания его типа, использовать всю мощь полиморфизма и т.д.
Не лучше ли сделать один Dictionary<int, IData>, а базе данных разнести информацию по таблицам следующим образом:
В «основной» таблице например BaseItems хранить автоинкрементный id и поля общие для всех типов IData.
Для каждого типа IData создать таблицу, которая будет хранить только поля специфичные для данного типа и id. И по id связать все эти таблицы с BaseItems.
Зачем хранить все в 4х Dictionary, а не в 1ом?
Спасибо за статью! Когда почти дочитал очень хотелось написать в коменте: Почему не сделать возможность задания прав как для конкретных пользователей так и для ролей. Но Вы все же это в принципе учли в самом конце статьи ))
Паттерн или не паттерн, или реализация паттерна это вопрос скорее философский и/или риторический.
Полностью согласен. Но для чего и зачем это в принципе может быть нужно?
А я разве утверждал обратное? В том то собственно и вопрос, что мы по сути пытаемся оптимизировать количество вызовов методов которые по сути ничего не делают и сразу вызывают return.
Вариант автора статьи. Я ведь очень подробно изложил свои выводы.
Для меня важно лишь определиться имеет ли смысл использовать данный паттерн.
В общих случаях, я думаю всем очевидно, что нет. Т.к. страдает простота, красота, читабельность и т.д. кода, увеличивается объем инфраструктурного кода, может возникнуть куча проблем с проектированием и рефакторингом из ничего и т.д. И в итоге можно получить проектирование ради проектирования…
Как я писал выше возможно это может иметь смысл в каких-то частных случаях, как вариант оптимизации, но лично я не вижу каких-то явных плюсов в том, что ВОЗМОЖНО сократится количество вызовов Dispose такой ценой.
Я просто не могу представить задачу или ситуацию когда использование этого паттерна в контексте .NET будет оправдано. Автор в статье упоминал про граф объектов… В частном случае, если классы этих объектов описывают относительно примитивные сущности, целесообразным будет использование структур, а не классов со всеми вытекающими плюсами типов значений над ссылочными и это даст ощутимую оптимизацию быстродействия и использования памяти, если выделять память сразу для больших групп таких объектов.
Возможно не совсем верная аналогия, но это можно сравнить с авто с АКПП и МКПП. И использование этого паттерна это попытка ехать на АКПП как на МКПП. Но если критичны возможности МКПП, не лучше ли изначально выбрать МКПП.
Ведь основные преимущества C# это скорость разработки и высокая сложность отстрелить себе ноги, а в данном случае мы получается пытаемся идти против этих основных концепций.
Опять же, буду рад объективной критике и примеру того когда этот паттерн даст ощутимые плюсы от своего использования.
Если делать API для узкого круга лиц и/или для проекта в котором критична скорость освобождения ресурсов, то вариант автора намного более предпочтителен.
Если же делать API «для всех», то однозначно только вариант допускающий множественные Dispose, т.к. это уже давно устоявшаяся практика для «всех» и в 1-ую все должно быть надежно и интуитивно понятно.
Но с другой стороны C# ведь в принципе не предназначен для систем реального времени и возможно концепция автора просто не имеет смысла, а в случаях когда критична скорость освобождения ресурсов следует изначально выбирать C++ и т.п. и полностью контролировать ситуацию. Буду рад объективной критике.
Спасибо автору за статью и всем за коменты, они не менее интересны.
Отличная статья. Паттерны проектирования очень хороши в теории, а на практике довольно часто просто рыдаешь когда их очень грамотно к месту применяют 'гуру' проектирования.