Комментарии 10
1. В промышленных системах программа не имеет прав на изменение метаданных. Т.е. если программа не видит какой-то таблицы или столбца — она не может их динамически создать. А если может — DB админа уволят на следующий день. Для создания прототипов — да — удобно, для серьезного софта — нет. Малые и средние проекты тоже требуют серьезного подхода.
2. Интерфейсы не могут содержать никакой вспомогательной логики. В этом плане POCO и partial classes намного удобнее, их можно расширять своими методами и данными.
Короче, ваш фреймворк построен на любительских принципах, которые в индустриальных масштабах нежизнеспособны. Что-то рельсы напоминает.
2. Интерфейсы не могут содержать никакой вспомогательной логики. В этом плане POCO и partial classes намного удобнее, их можно расширять своими методами и данными.
Короче, ваш фреймворк построен на любительских принципах, которые в индустриальных масштабах нежизнеспособны. Что-то рельсы напоминает.
Касательно №1. Тут и небыло ничего сказано о промышленных системах :). Само собой, что в больших и многих средних корпоративных системах, нужно проектировать свои слои и реализовывать их под нужную задачу. Есть сайты, программы, где работает только один человек и нужно создавать быструю и простую реализацию. На них данная штука и ориентирована. Также, вы можете атрибуту указать чтобы движок не изменял метаданные. Если вам того хочется :)
Касательно №2. Логики в слое доступа к данным быть и не должно, но если вам так уже хочется добавить логику, используйте Extension методы для данного интерфейса. В системе есть даже вспомагательные классы для выделения прототипа из указателя на интерфейс. Если даже не хотите использовать методы расширений, в аттрибуте интерфейса укажите custom-класс для прототипирования, и он будет без динамического создания :)
Попробуйте поговорить с разработчиками, которые работают с рельсами :) и скажите, что там любительские принципы :)
Спасибо, за отзыв о статье.
Касательно №2. Логики в слое доступа к данным быть и не должно, но если вам так уже хочется добавить логику, используйте Extension методы для данного интерфейса. В системе есть даже вспомагательные классы для выделения прототипа из указателя на интерфейс. Если даже не хотите использовать методы расширений, в аттрибуте интерфейса укажите custom-класс для прототипирования, и он будет без динамического создания :)
Попробуйте поговорить с разработчиками, которые работают с рельсами :) и скажите, что там любительские принципы :)
Спасибо, за отзыв о статье.
По поводу 1. Спорить не буду, у каждого свои понятия о прототипах как малых проектах.
По поводу 2. Если есть возможность использовать нормальные классы, зачем заморачиваться интерфейсами вообще? Т.е. extensions methods — это хорошо, но extension fields и properties — еще, насколько мне известно, не придумали, а имитация их достаточно энергозатратна.
По поводу рельсов. Я не говорил, что рельсы построены на любительских принципах. Возможно я плохо выразился, но я имел ввиду, что ваш фреймворк рельсы напоминает. А конкретно он рельсы напоминает тем, что база автоматом подстраивается под модель данных.
По поводу 2. Если есть возможность использовать нормальные классы, зачем заморачиваться интерфейсами вообще? Т.е. extensions methods — это хорошо, но extension fields и properties — еще, насколько мне известно, не придумали, а имитация их достаточно энергозатратна.
По поводу рельсов. Я не говорил, что рельсы построены на любительских принципах. Возможно я плохо выразился, но я имел ввиду, что ваш фреймворк рельсы напоминает. А конкретно он рельсы напоминает тем, что база автоматом подстраивается под модель данных.
№1) я только предложил ещё один упрощённый вариант для начинающих) кому будет проще реализовывать слой доступа к данным так чем описывать всё ручками, хоть ручками они опыта наберут)
№2) простой пример заморочки с интерфейсами: есть приложение, которое работает с MsSql базой данных. мы прописываем все аттрибуты Linq2Sql для прототипа. Затем, нужно поменять субд на MySql или MongoDB. и нам приходится ручками переписывать эти прототипы и их аттрибуты. а интерфейс — это простая замена своего языка описания прототипа таблицы, на основе которого будет создан класс с нужными аттрибутами на этапе выполнения приложения.
Когда родилась данная идея основанная на лени (года 2 назад), я и понятия не имел о рельсах. А оказалось создал велосипед. Ну с кем не бывает?)
№2) простой пример заморочки с интерфейсами: есть приложение, которое работает с MsSql базой данных. мы прописываем все аттрибуты Linq2Sql для прототипа. Затем, нужно поменять субд на MySql или MongoDB. и нам приходится ручками переписывать эти прототипы и их аттрибуты. а интерфейс — это простая замена своего языка описания прототипа таблицы, на основе которого будет создан класс с нужными аттрибутами на этапе выполнения приложения.
Когда родилась данная идея основанная на лени (года 2 назад), я и понятия не имел о рельсах. А оказалось создал велосипед. Ну с кем не бывает?)
1) Сомневаюсь, что новички вообще найдут ваш проект и будут его использовать. Скорее те, кому интересно написание LINQ-провайдера.
2) Если вам не нравится идея прописывания атрибутов от различных провайдеров на одних и тех же классах — никто не мешает
а) вынести атрибуты/описание маппинга в отдельный файл, как это позволяют nHibernate, Linq2Sql, EF, etc.
b) придумать свой формат описания классов и генерировать их c# код своим код-генератором на момент билда.
c) придумать свои аттрибуты маппинга и PostSharp-ом преобразовывать их в конкретный вариант под выбранного провайдера.
Никогда не поздно сказать себе, что проект, в который вбухано столько времени, энергии, души, просто очередной вариант накопления опыта.
Опыт — вот главная цель.
2) Если вам не нравится идея прописывания атрибутов от различных провайдеров на одних и тех же классах — никто не мешает
а) вынести атрибуты/описание маппинга в отдельный файл, как это позволяют nHibernate, Linq2Sql, EF, etc.
b) придумать свой формат описания классов и генерировать их c# код своим код-генератором на момент билда.
c) придумать свои аттрибуты маппинга и PostSharp-ом преобразовывать их в конкретный вариант под выбранного провайдера.
Никогда не поздно сказать себе, что проект, в который вбухано столько времени, энергии, души, просто очередной вариант накопления опыта.
Опыт — вот главная цель.
Относительно опыта — согласен. Тут его было получено не мало. Даже глядя на ручную генерацию IL-кода. Касательно выноса маппинга в отдельный файл — в данном случае для linq2sql mssql в памяти и генерируется xml файл маппинга. А он всё равно для каждой ORM будет свой. Свой формат — я уже писал причину его отсутствия. PostSharp — уже стал платным, и неизвестно что с ним будет дальше.
Касательно всего данного холивара: я не понимаю вашей агрессии на то, что это очередной велосипед. Времени на него было в сумме потрачено около пары недель. Не более. Как раз таки для опыта. И выложен он сюда в сорцах не для того, чтобы рассуждать что лучше использовать корпоративные решения и шаблоны, а для того, что кому-то могут пригодиться те грабли, на которые наступал и я. Проект не продаётся, и нигде не писалось, что это последняя инстанция правоты :)
Кто захочет — возьмёт. Не захочет — конечно есть решения на порядок лучше и производительнее :)
Касательно всего данного холивара: я не понимаю вашей агрессии на то, что это очередной велосипед. Времени на него было в сумме потрачено около пары недель. Не более. Как раз таки для опыта. И выложен он сюда в сорцах не для того, чтобы рассуждать что лучше использовать корпоративные решения и шаблоны, а для того, что кому-то могут пригодиться те грабли, на которые наступал и я. Проект не продаётся, и нигде не писалось, что это последняя инстанция правоты :)
Кто захочет — возьмёт. Не захочет — конечно есть решения на порядок лучше и производительнее :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
AcroDb. Новый провайдер данных