Лучшие стратегии при работе с микро ORM?

Я начал использовать PetaPOCO и Dapper, и у них обоих есть свои ограничения. Но, наоборот, они настолько сильны, что не могут существовать, чем Entity Framework, и я склоняюсь к ограничениям.

Мой вопрос: есть ли ORM, который позволяет нам конкретно определить отношения "один ко многим", "многие-к-одному" и "многие ко многим"? Как Dapper.Net, так и PetaPOCO, они как бы реализуют хакерский способ подделать эти отношения, и, кроме того, они даже не очень хорошо масштабируются, когда у вас может быть 5-6 объединений. Если нет ни одного микро ORM, который бы позволил нам справиться с этим, тогда мой второй вопрос: следует ли мне отпустить тот факт, что эти микро ORM не так хороши в определении отношений и создании нового объекта POCO для каждого отдельного типа запроса, который я бы выполнял, включая эти типы множественных соединений? Может ли этот масштаб хорошо?

Надеюсь, я ясно понимаю свой вопрос. Если нет, сообщите мне.

ОТВЕТЫ

Ответ 1

Я обычно выполняю следующие шаги.

  • Я создаю свою модель просмотра таким образом, чтобы представлять точные данные и формат, которые я хочу отобразить в представлении.
  • Я запрашиваю прямо из базы данных через PetaPoco на мои модели просмотра.

В моей ветке есть

T SingleInto<T>(T instance, string sql, params object[] args);

который принимает существующий объект и может сопоставлять столбцы непосредственно с ним, сопоставляемые именем. Это блестяще работает для этого сценария.

Мое отделение можно найти здесь, если необходимо. https://github.com/schotime/petapoco/

Ответ 2

они даже не очень хорошо масштабируются, когда у вас может быть 5-6 соединений

Да, они этого не делают, но это хорошо, потому что, когда система, которую вы будете строить, начинает становиться сложной, вы можете делать все, что хотите, без штрафных санкций или головных болей.

Да, я пропустил, когда мне не нужно было писать все эти JOINS с Linq2SQL, но затем я создал простой инструмент для записи общих объединений, поэтому я получаю базовый SQL для любого объекта, а затем я могу построить оттуда.

Пример:

[TableName("Product")]
[PrimaryKey("ProductID")]
[ExplicitColumns]
public class Product {
    [PetaPoco.Column("ProductID")]
    public int ProductID { get; set; }

    [PetaPoco.Column("Name")]
    [Display(Name = "Name")]
    [Required]
    [StringLength(50)]
    public String Name { get; set; }

            ...
            ...

    [PetaPoco.Column("ProductTypeID")]
    [Display(Name = "ProductType")]
    public int ProductTypeID { get; set; }

    [ResultColumn]
    public string ProductType { get; set; }

            ...
            ...


    public static Product SingleOrDefault(int id) {
        var sql = BaseQuery();
        sql.Append("WHERE Product.ProductID = @0", id);
        return DbHelper.CurrentDb().SingleOrDefault<Product>(sql);
    }
    public static PetaPoco.Sql BaseQuery(int TopN = 0) {
        var sql = PetaPoco.Sql.Builder;
        sql.AppendSelectTop(TopN);
        sql.Append("Product.*, ProductType.Name as ProductType");
        sql.Append("FROM Product");
        sql.Append("    INNER JOIN ProductType ON Product.ProductoTypeID = ProductType.ProductTypeID");
        return sql;
    }

Ответ 3

Помогла ли QueryFirst помощь? Вы получаете скорость микро ормсов, с дополнительным комфортом ошибки при каждой ошибке-компиляции-времени, плюс intellisense как для ваших запросов, так и для их вывода. Вы определяете свои объединения в SQL, как предназначение Бога. Если вы печатаете условия соединения, вы действительно подслушиваете, DBForge может быть ответом, и поскольку вы работаете в SQL, эти инструменты совместимы, и вы не заперты.