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

c# dapper massive orm petapoco

Вопрос

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

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

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

Принятый ответ

Обычно я выполняю эти шаги.

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

В моей ветке у меня есть

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

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

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


Популярные ответы

они даже не очень хорошо масштабируются, когда у вас может быть 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;
    }


Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему
Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему