ORM for new Meta document managment system.
https://github.com/anesvijskij/meta.orm/blob/master/Meta.ORM/Meta.ORM.Tests/Query/QueryTests.cs Тесты даже не падают! И в них во всех один и тот же пример подразумевается!
- В некоторых ORM разрешают заменить стандартный репозиторий своим, расширенным, в котором, например, реализованы какие-то частые операции. Делать ли поддержку таких кастомных репозиториев и если да, то как это лучше сделать?
- В EF при вызове ряда методов-расширений (Where, Select, OrderBy), меняется тип возвращаемого результата (но не тип дженерика). Например, после вызове OrderBy возвращается объект, для которого становятся доступны методы ThenBy и ThenByDescending. Стоит ли идти таким путем или оставить как есть и считать что последовательность вызовов OrderBy задает полседовательность свойств, по которым ведется сортировка? А Where склеиваются между собой через AND?
- Сделать ли методы Query методами-расширениями как в LINQ? Или в этом нет необходимости? Я так понимаю в LINQ сделано через расширения, чтобы в т ч для всех реализаций IQuerable эти методы работали одинаково, отдавая нюансы конвертации в SQL (ну вообще - выполнения) реализации IQueryProvider.
- Стоит ли унаследовать Query от IEnumarable и сделать так, чтобы вызов Enumerate() всегда приводил к выполнению запроса. Не будет ли в этот момент путаницы, ведь часть методов такого объекта будут его собственные, а часть (причем с похожими именами и сигнатурами) придет от методов-расшений IEnumerable.
- Стоит ли вводить свои выражения MetaExpressions вместе с грамматикой и прочим (в тестах есть примеры сконструированных выражений, и сериализованных) вместо LINQ.Expression. Как альтернатива - можно разрешить писать выражения на подмножетсве языка C#, каким-то образом такие выражения парсить (да хоть тем же Antlr) и потом при помощи Visitor конвертировать их напрямую в дерево LINQ.Expression. И уже потом это дерево конвертировать в SQL. Из плюсов - нет своего языка. Из минусов - LINQ.Expression очень громоздкие и неудобные, руками ты код в виде Expressions не попишешь особо, а писать строку, содержащую C# можно, но в ней не будет все равно работать IntelliSence (А для кастомного синтаксиса я смогу запеилить свой IntelliSence =) ), а значит там будет все равно сложно избежать ошибок. К тому же код на C# подразумевает работу над объектом, которого на самом деле не будет.
- Если делать свои выражения, стоит ли их делать Generic-ами. Там есть такие примеры. Проблема в том, что определить в design-time тип выражения не всегда возможно (например MetaExpression.Property("Name") - должно бы быть типа MetaExpression, но это никак не отловить без модели). Но типизированные таким образом выражения чуть проще писать на C#.
- Нужен ли вообще интерфейс IEntity? Я его ввел по-старинке и ради набора методов GetPropertyValue. Но нужен ли этот метод в реальности? Если программист хочет написать конкретный код для бизнес-логики, он создает обертки над сущностями (генерирует даже) и работает с ними как с POCO объектами. Если же это некий общий код, то почти всё (условия, фильтры, etc) можно заменить на MetaExpression-ы. Или на LINQ.Expression-ы. Пока вижу проблему только в реализации проекций (Select), их не понятно как писать в общем виде. Ну а заполнение полей сущности при подъеме из БД и так надо делать, создавая LINQ-выражение и компилируя его, для максимальной скорости заполнения полей (чем возиться со словарями любых ключей).
- Вопрос чисто по кодингу. Я включил StyleCop с настройками по-умолчанию, и он мало того, что реально заставляет писать код определенным образом, но и ругается на веши, с которыми я не согласен. Например хочет, чтобы я в явном виде писал this. или например вносил using внутрь namespace, а не во вне, и т.д. Использовать ли StyleCop? И если да, то может существует какой-то хороший готовый набор правил?