it-swarm-eu.dev

Jaké jsou argumenty PROTI použití EntityFramework?

Aplikace, kterou v současné době buduji, používal uložené procedury a ručně vytvořené modely tříd k reprezentaci databázových objektů. Někteří lidé navrhli použít Entity Framework a uvažuji o přechodu na to, protože nejsem tak daleko do projektu. Můj problém je, že mám pocit, že lidé, kteří se hádají o EF, mi jen říkají dobrá stránka věcí, ne špatná strana :)

Mé hlavní obavy jsou:

  • Chceme ověření na straně klienta pomocí DataAnnotations a zní to, jako bych musel stejně vytvářet modely na straně klienta, takže si nejsem jistý, že EF by ušetřil tolik času na kódování
  • Chtěli bychom udržovat třídy co nejmenší, když procházíme sítí, a četl jsem, že použití EF často zahrnuje další data, která nejsou potřebná
  • Máme komplexní databázovou vrstvu, která protíná více databází, a nejsem si jistá, že to EF zvládne. Máme jednu společnou databázi s věcmi, jako jsou uživatelé, stavové kódy, typy atd. A více instancí našich hlavních databází pro různé instance aplikace. SELECT dotazy mohou a budou dotazovat ve všech instancích databází, uživatelé však mohou upravovat pouze objekty, které jsou v databázi, na které aktuálně pracují. Mohou přepínat databáze bez opětovného načtení aplikace.
  • Režimy objektů jsou velmi složité a často se jich účastní poměrně málo spojení

Argumenty pro EF jsou:

  • Konkurence. Nemusel jsem kódovat šeky, abych zjistil, zda byl záznam aktualizován před každým uložením
  • Generování kódu. EF pro mě může generovat modely dílčích tříd a POCO, ale nejsem pozitivní, což by mi opravdu ušetřilo tolik času, protože si myslím, že budeme stále muset vytvořit modely na straně klienta pro ověření a některé vlastní metody analýzy.
  • Rychlost vývoje, protože bychom nemuseli vytvářet CRUD uložené procedury pro každý databázový objekt

Naše současná architektura sestává z služby WPF, která zpracovává volání databáze prostřednictvím parametrizovaných uložených procedur, objektů POCO, které jdou do/ze služby WCF a klienta WPF, a samotného desktopového klienta WPF, který transformuje POCO do třídy Modely za účelem ověření a Vázání dat.

Takže moje otázka zní, je EF na to správný? Existují nějaké úskalí ohledně EF, o kterých nevím?

31
Rachel

Nedávno jsem hodnotil Entity Framework a nejlepší místo, které jsem našel pro problémy a chybějící funkce, bylo: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Položky s největším počtem hlasů:

  1. Podpora výčtů. Tenhle je docela velký, ale v současné době existuje několik řešení
  2. Vylepšené generování SQL. Rychlost je opravdu důležitá zejména pro aplikace na podnikové úrovni, ale zdá se, že s EF4 se hodně zlepšila
  3. Podpora více databází. Požadavek na jakoukoli velkou aplikaci.

V seznamu Hlas uživatele je mnoho dalších problémů.

Pokud jde o vedlejší poznámku, jsem velmi nadšený nadcházejícím vydáním EF 4.1, které bude zahrnovat přístup Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15 /ef-4-1-release-candidate-available.aspx

To by mě ve skutečnosti mohlo donutit vyzkoušet EF ve výrobní aplikaci.

7
Mag20

Udělat větev za chybu/funkci pomocí EF může být v době sloučení pozoruhodně bolestivé. Představte si, že dvě větve A a B provedou změny v databázi (což se pravděpodobně stane hodně během raných fází nového projektu).

Sloučíte všechny „normální“ soubory - cs soubory atd. A pak je čas sloučit Model.edmx. A najednou nejen slučujete logická mapování mezi vaším objektovým modelem a databází, ale také polohy tabulek v entitním diagramu.

Sloučení Model.edmx je tak bolestivé, že jsme přijali celkem ošklivou cestu, která funguje:

  • Během slučování stačí vybrat všechny sloučení od jednoho nadřazeného. Na čem nezáleží; Soubor si brzy opečete:
  • Vrátit Model.edmx jednomu z rodičů.
  • Migrujte databázi do nového sloučeného stavu.
  • Otevřete Model.edmx a "Aktualizovat model z databáze".
  • Přejmenujte všechny navigační vlastnosti opékané během sloučení.
7
Frank Shearar

EF vám chybí několik dalších výhod:

  • Můžete mít tabulky rozpětí entity
  • Tabulku můžete rozdělit do mnoha typů entit
  • Můžete vygenerovat entity z databáze (tj. Databáze jako hlavní přístup)
  • Můžete vygenerovat databázi z entit (tj. Kód jako hlavní přístup)
  • Dotazy LINQ jsou přeloženy do dotazů SQL, čímž se zvyšuje jejich výkon.

Nevýhody (zejména pokud používáte ověřování):

  • Musíte vytvořit atribut [MetadataClass], který ukazuje na jinou třídu, která má vlastnosti, které chcete ověřit, s příslušnými atributy ověření. Všechny vlastnosti jsou typu object, takže je to jen pro čtení metadat. Stále hodně extra neaktivní kód.
  • Používání EntityFramework je odlišný koncept, než jak je navrženo něco jako NHibernate (a rodičovský Java verze)). EntityFramework nejlépe funguje v režimu připojený, kde objekty vždy používají živé spojení. NHibernate a podobné nástroje ORM fungují nejlépe v režimu odpojeno, kde se připojení používá pouze při načítání/ukládání dat.

To jsou dvě největší stížnosti, které mám. Existuje celá řada výhod, ale velmi dobře byste mohli získat stejné výhody z NHibernate. Pokud je EntityFramework na stole, nechte tým také vyzkoušet NHibernate a udělejte rychlé střílení pro/proti pro váš projekt.

Problém třídy metadat je bolest hlavy, ale naštěstí mám jen tolik entit, které vyžadují validační značky.

Nedostatek skutečně odděleného režimu pro vaše objekty omezuje to, co můžete dělat ve webovém prostředí. Připojený režim je lepší pro stolní aplikace, kde vzniklo množství inovací společnosti Microsoft. Odpojený režim je možný, ale velmi bolestivý. V tomto případě je nejlepší použít alternativní nástroj.

5
Berin Loritsch

Jedna věc, ve které Microsoft není příliš dobrý, je zaostalý srovnatelnostkompatibilita, zejména pokud jde o nové technologie

Konkrétně EF1 (.net 3.5) se velmi liší od EF4 (.net 4.0) - to samé by se mohlo objevit pro další verzi.

Chvíli jsem počkal a uviděl, jak tato technologie zraje.

Do té doby zvažte použití nHibernate - není to ekvivalentní, ale je zralé a široce používané.

2
Ophir Yoktan
  • Jednoduše ... Domain Model je zřídka replika relačního modelu v databázi. Mapování některých tabulek na třídu a házení přes drát je tedy prostě lenost. Tabulky se mohou místně mapovat do 1 objektu, i když databáze obsahuje 3 různé tabulky. Návrh databáze inteligentně.
  • 2. tento materiál EF nemůže generovat určité dotazy a budete je muset přesto napsat.
  • 3. Doménový model nemapuje přímo na služby .. Jeden bude chtít tlačit co nejmenší sadu dat přes drát jako DTO .. ​​zvláště, pokud bude komunikovat s mobilními aplikacemi.
  • 5Th test-schopnost ... Nelze vytvořit dostatečně granulární testy, které zajistí dostatečnou regresi proti změnám kódu ... vše snadno
    přestávka ...

Mohl bych napsat 10stránkový diatribe. Ale pokud právě píšete nějakou aplikaci pro vyhození pro společnost X .., na které vám záleží. Ale pokud vyvíjíte softwarový produkt ... budete muset být mnohem víc anální

1
user104468

Podívejte se na toto: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Hlavní body jsou:

  • Nedostatek líného nakládání
  • Nedostatek neznalosti vytrvalosti
  • Formát souboru používaný k uložení modelu entity obsahuje vizualizační prvky a samotný model entity způsobuje problémy s sloučením v týmovém prostředí.

Všimněte si, že výše uvedený odkaz mluví o EF1.

Také tento odkaz: http://ormeter.net/ ukazuje, že EF není nejlepší ve srovnání s jinými ORM ve výkonu a podpoře LINQ.

0
M.Sameer