Прайш се на луд пак, айде почивай си от мене.
Patterns'n'shit
Добре, минималисти. ORM, big shit. Как си правите ентититата?
Вариант 1 - всяко ентити си е само по себе си
public class Shit
{
public long Id { get; set; }
public string Colour { get; set; } // mind the gap
public DateTimeOffset CreatedOn { get; set; }
}
Вариант 2.1 - нека сме по- cool, имаме общо между повечето таблици ID-то over and over again? Но това би било проблем при ID= PK & FK или Composite PK, тогава ще пишете ли още интерфейси?
public interface IEntity<TId>
{
TId Id { get; set; }
}
public class Shit : IEntity<long>
{
public long Id { get; set; }
public string Colour { get; set; } // mind the gap
public DateTimeOffset CreatedOn { get; set; }
}
Вариант 2.2 - overkill-вате, но е cool
public interface IEntity<TId>
{
TId Id { get; set; }
}
public abstract class AbstractEntity<TId> : IEntity<TId>
{
public TId Id { get; set; }
// override equals
// override hash
// override ==
// override whatever else
}
public class Shit : AbstractEntity<long>
{
public string Colour { get; set; } // mind the gap
public DateTimeOffset CreatedOn { get; set; }
}
Вариант 2.3 - имате soft delete, delete, ентитита само с createdon, ентитита с createdon + updatedon, etc. и си правите интефейси с или без абстрактни класове.
Наследяването е пълен кенеф по всякакви поводи,по-добре си направи няква MVC композиция с два класа
п.с.гласувам за 2.1 
Database first има прекалено много предимства, може би е добре да е в отделна тема ако се дискутира полусериозно
ORM-a е антипатерн. Не мога да разбера какво му харесват хората. При мен се ползва, защото тъпацит ене разбират от бази данни и не могат да напишат една SQL заявка, нито пък могат да програмират - ако спринга няма анотация за нещо си, са до там.
ORM се ползва заради кеширането, бай теоретик. Извличал съм и сглобявал секви обекти от базата, ама кеш нанай си. Ускорява нещата хиляди пъти като се кешира.
Според зависи, с ORM-а мажеш с лопатата една идея по- бързо. Като трябва PoC да вдигна за 2-3 дни, ORM, Automapper, ей ви Proof. Причина 1 е, че няма време (макар, че за 1-2 таблици, ADO.NET печели за времето, лично мое мнение). Причина 2 е, че екипът не иска / не се чувства комфортно / няма достатъчно познания по базите. Трета е чисто политическа, архитекта е казал така и бръмчи като жигула на баир, че така го искал и така да се направи. Виждал съм и трите причини. Вероятно има и още.
@Rabin, ти винаги може да си имплементираш кеш. На Хайбърнейта имаш повече контрол, на Ентити Фреймуърка имаш повече асумпции от тези преди теб. На много голяма база може да се застреляш, защото в .NET-а имаш ограничение колко да са ти големи обектите, което ограничение може да изключиш, но е там да ти напомни, че ако не знаеш защо държиш толкова памет, вероятно не трябва да държиш толкова памет.
Кис кис, дядовците много го обичат туй упражнение. Точно там са големите науки, туй диви интерфейси, durty стейтове, абе много сложно и научно е. После гасим лампите и на борсата. Точно след такъв опит.
Преди гледах да правя оптимизации, но са ми натяквали, че моето време е по- скъпо от хардуерното, а и самата оптимизация ми е създавала проблеми и в крайна сметка, ако нямам точно специфичното изискване да оптимизирам, чуствам се напълно спокоен да не го оптимизирам. Е, добре, ако някой ми прави 1000 пъти стринг.реплейс, тогава го преправям на стрингбилдър, но само в такива изключения. Да тегли, викат, че хардуера бил евтин.
Пък ако накрая фейлне, здраве да е, ще ядем кебапчета. Фирми бол.
ORM без кеш не е липса на оптимизация както го изкарваш. Това е жизнена необходимост, както слънцето и въздуха за всяко живо същество (Г. Димитров). Да не си php мазач, че да приказваш такива неща?
Не, защитавах ADO.NET vs EF/NHibernate. Ако не ползваш ORM и искаш да кешираш, ще трябва ти да си кешираш. Но имаш ли наистина нужда от кеш всеки път? Може би има и light ORM-и, които само мапват. Виждал съм един такъв custom написан, който беше без кеш, само мапваше. Бяха крали от хайбърнейт мапинг спецификацията с XML, но защо не бяха сложили и други неща - вероятно е нямало време. Били го написали малко преди ЕФ да излезе и така си стои, сигурно и до днес.
Наясно ли си как кешира самия SQL Server, или каквато база там ползваш? Дришльото че не е наясно е ясно
Не напълно, но да четеш в паметта е по- бързо от да търкаляш по мрежата.
Да, освен в готините случаи когато некой барне нещо дето ти си кеширал
Plot twist, ше ги вземам от редис, а уъркър ще следи за промени в базата и ше ъпдейтва редиса. Не съм го правил.
ORM не се ползв азаради кеширането. Кеширане може да имаш на всякъде. Ползва се, защото масовката не може да обърне ResultSet-a в обекти, а и не може да напише елементарна SQL заявка. ORM-a e бавен, и ням акак да е по-бърз от plain JDBC, защото най-малкото го използва отдолу.
Едно е ПоК, друго е продуктивен код. Примерно е мъка да правиш DB migrations с ORM. Това което си спестил после ти излиза десеторно през носа.
Ако правиш джойнове, имаш процедури, и т.н. е още по-голяма мъка. ORM-a става само да мапваш елементарни таблички без връзки с други таблици. Това вече може да е мой пропуск, но аз не знам как може да направиш рекурсивна заявка с JPA
типично outsource мислене, за продукт това по-скоро не е вярно, освен ако не се впускаш в безсмислени микрооптимизации.
проблема на кеша е, чене знаеш кога да го инвалидираш :) за read-only данни е ок, но там където се пише и променя е проблем
Ми... нямам си идея. Имаш предвид ред в таблицата да си реферира ред в същата таблица? Виждал съм такива 2 пъти в житова си, ДБ-тата ми бяха написали процедура да си я извикам, а и тогава бачкахме без ОРМ. Пък и да му хванеш всичко иска време, има време.
ПС: Да, бачкал съм повече аутсорс във всичките известни такива фирми. Преди малко години се отрекох от тая работа, щото не искам да съм ковра на повикване, пък и да правиш едно и също на поточна линия е мъка. Да ме пратят контракт някъде е интересно, но в такъв случай по- добре сам да се контрактвам.