Vývoj v C# + Oracle ODP.NET + EntityFramework

18.2.2018 20:27 | Přečteno: 2832× | windows | poslední úprava: 18.2.2018 20:28

V dobách několik let zpět se rozhodlo, že vývoj nového firemního IS se postaví na C# + ODP.NET + Entity Framework.

Historie a aktuální stav

Současný IS je postaven jako tlustý klient na Visual FoxPro + Oracle. Nový IS je formou web app, která běží na IIS a je napsána pod C# za pomocí EntityFrameworku a ODP.NETu pro komunikaci s OracleDB.

Aktuální problém je, že mně programátoři neustále otravují s tím, proč jim něco nefunguje ve Visual Studiu, jakou verzi klienta mají použít, jak to mají nainstalovat, proč jim to nejde na jejich domácím PC ve Visual Studio Express atd. Fakt mně to sere. Nechápu, proč já jako systémák mám řešit jejich program na jejich PC.

Celá věc vygradovala v pátek, kdy jsem musel být v jobu asi do 20:30 kvůli tomu, že mi hlavní programátor IS ve čtvrtek řekl, abych zaktualizoval Oracle klienta na 12.2 na serveru s IIS, kde běží IS. Prý kvůli tomu, že si nainstalovat VS2017 a potřebuje novějšího oracle klienta a celý vývojový prostředí a produkci chce kvůli tomu překlopit na novější verze.

Nebudu napínat, v pátek zjistili, že jim nejde logování do db, používají elmah. Nevěděli proč, tak to přepli na logování do souborů. Pak zjistili, že jim nechodí odesílání emailů. Nebudu natahovat, páteční snažení zjistit, kde je chyba, skončila tak, že jsem obnovil VM s IIS z doby před upgradem a hlavní programátor dohrál změny, které do pátka udělal.

Kde je problém?

Problém je naprosto jednoduchý a zároveň smutný, vývojáři hafec let vyvíjejí a staví na něčem, o čem nemají ani páru. Oni vůbec nevědí, jak to funguje, co je ve skutečnosti potřeba pro funkci, jak je vše interně propojeno a navázáno. Prostě si něco nainstalovali, vyzkoušeli, řekli si, že je to parádní a používají to. Dokumentaci nečetli, asi jim to nepřišlo důležité. Když něco nejde, tak zkusí do projektu nakopírovat nějakou knihovnu z Oracle Clienta, začne to fungovat a jsou spokojeni. Používají ODP.NET a absolutně neví, jaký je rozdíl mezi managed a unmanaged verzemi apod.

Páteční incident už byla poslední kapka, kdy jsem si řekl, že už na ně totálně seru a nebudu jim s ničím pomáhat. Já to nevyvíjím, nevím, proč bych měl řešit, jak to mají postavené, jaké knihovny používají apod. Když už bych měl něco řešit, tak nasazení podle jejich dokumentace, která vzhledem k jejich dosavadním znalostem je nulová.

Tak co teda?

Šel jsem naposledy do sebe a přes víkend jsem si pročetl dokumentaci a snažil se co nejvíce pochopit, jak jejich projekt funguje, co využívají, co je potřeba, jaké verze a jak lze mixovat, zda jde mixovat verze knihoven, za jakých podmínek apod. Výsledkem je záznam do firemní wiki, který jsem jim poslal. Tento záznam chci i zveřejnit, kdyby řešil někdo někdy něco podobného. Takže tady to je.

Oracle + .NET + Entity Framework

• Oracle ODP.NET
• Kompatibilita
• Rozdílené verze knihoven
• Verze databází
• Podporovaná konfigurace
• Nasazení - druhy klientů, runtime apod.
• Oracle a integrace s Visual Studio
• Podpora více verzí na jednom PC
• Entity Framework (EF)
• Entity Framework Core (EF Core)
• Co se při vývoji používá

Oracle ODP.NET

ODP.NET je implementace .NET vrstvy, která volá knihovny Oracle klienta, viz Data Provider for .NET Developer's Guide.
Jsou zde tři typy driveru Oracle Data Provider for .NET (ODP.NET) :

• ODP.NET - Managed Driver (install)
• 100% .NET kód, je to implementace ODP.NET v jedné knihovně, vývojář může nasadit jednu assembly do deploy balíčku, který je ve finále menší jak 10MiB
• lze tedy být nasazeno jako jednoduchá reference do "bin" adresáře projektu
• není potřeba oracle client ani nic dalšího
• používá se namespace "Oracle.ManagedDataAccess.Client"
• v základu stačí tedy jedna knihovna "Oracle.ManagedDataAccess.dll", pokud se využívají transakce, tak je u starších verzí .NET potřeba "Oracle.ManagedDataAccessDTC.dll", pokud Entity Framework, tak "Oracle.ManagedDataAccess.EntityFramework.dll"
• ODP.NET - Unmanaged Driver (install)
• obsahuje více featurek než "managed driver", protože poskytuje přístup i k funkcím oracle db klienta
• oracle client je tedy vyžadován
• používá se knihovna "Oracle.DataAccess.dll" + samozřejmě spoustu dalších
• výkonově na tom bývá lépe
• je třeba mít přesnou verzi Oracle Clienta s přesnou verzí unmanaged driveru, rozhodně nic nemixovat (nic nedávat do projektu, používat verzi v oracle klientovi)
• ODP.NET Core
• je navržen pro multiplatformní nasazení pomocí .NET Core (zatím jsou podporované platformy Windows a Linux)

Přesné rozdíly mezi Managed a UnManaged drivery popisuje Oracle zde :

• Differences between the ODP.NET Managed Driver and Unmanaged Driver
• Configuration differences between ODP.NET, Managed Driver and ODP.NET, Unmanaged Driver

Kompatibilita

Je myslím jasné, že míchat v projektu managed a unmanaged drivery není dobrý nápad.
Taktéž je třeba se držet podporované kombinace ODP.NET a Oracle klienta.

Rozdílené verze knihoven

Pokud projekt linkujeme k nějaké verzi dll, je třeba, aby přesná verze dll byla i na straně, kde sw nasazujeme. Pokud toto nemůžeme z nějakého důvodu zajistit a víme, že naše použití v kódu funguje na různých verzích knihoven, tak to můžeme řešit třeba jako tento člověk zde pomocí "AppDomain.CurrentDomain.AssemblyResolve" :

• C#: Target Any Version of Oracle.DataAccess.dll in Runtime

Verze databází

ODP.NET je samozřejmě zpětně kompatibilní, což znamená, že s aktuální verzí se lze připojit do starší verze OracleDB, ale i naopak se starší verzí do novější OracleDB, viz Doc ID 207303.1 :

Kompletní schema kompatibility pak viz :

Podporovaná konfigurace

Je opět vedena u Oracle, viz Doc ID 726240.1 :

Nasazení - druhy klientů, runtime apod.

Pro nasazení jsou tři možnosti (resp.5):

1) nasadit ODAC pomocí universálního instalátoru Oracle s podporou Visual Studia (tzn. nasazení na počítače vývojářů, má v sobě 32bit)

• ODTwithODAC122010.zip

ODAC OUI obsahuje :

• Oracle Data Provider for .NET
• Oracle Providers for ASP.NET
• Oracle Database Extensions for .NET - for upgrade only
• Oracle Developer Tools for Visual Studio - for 32-bit only
• Oracle Provider for OLE DB
• Oracle Services for Microsoft Transaction Server
• Oracle ODBC Driver
• Oracle SQL*Plus
• Oracle Instant Client

2) Nasazení Runtime ke klientům
a) nasadit ODAC z nuget repositáře

• https://www.nuget.org/

b) použít ODAC universální instalátor (je jen 64bit, pro nasazení podpory 32bit se musí použít balíček výše v bodě 1)

• ODAC122010_x64.zip

ODAC OUI obsahuje :

• Oracle Data Provider for .NET
• Oracle Providers for ASP.NET
• Oracle Provider for OLE DB
• Oracle Services for Microsoft Transaction Server
• Oracle ODBC Driver
• Oracle SQL*Plus
• Oracle Instant Client

c) použít ODAC XCopy pro rozsáhlejší nasazení :

• ODAC122010Xcopy_32bit.zip
• ODAC122010Xcopy_x64.zip

ODAC XCopy obsahuje :

• Oracle Data Provider for .NET
• Oracle Providers for ASP.NET
• Oracle Provider for OLE DB
• Oracle Services for Microsoft Transaction Server
• Oracle Instant Client

3) Oracle Client Full
Obsahuje úplně vše (včetně admin nástrojů apod.) kromě integrace s Visual Studio

Oracle a integrace s Visual Studio

Pro integraci se buď použije ODTwithODAC (viz bod 1), nebo lze nainstalovat jakýkoli jiný runtime pro Oracle a k němu zvlášť doinstalovat Oracle Developer Tools for Visual Studio :

• ODTforVS2017_122010.exe (VS2017 + 12.2.0.1.0)
• ODTforVS2015_122010.exe (VS2015 + 12.2.0.1.0)
• ODTforVS2013_121025.exe (VS2013 + 12.1.0.2.4 - již tedy není podpora pro Oracle 12.2)

Podpora více verzí na jednom PC

Příklady jsou uvedeny v : Oracle Data Provider for .NET FAQ
Tzn., že je možné na jednom PC provozovat více verzí ODP.NET, je taktéž možné nasadit více verzí na IIS tím, že se pro každou verzi definuje jiný aplikační pool s jinou verzí.

Entity Framework (EF)

Jedná se o OSS framework (github), který nám umožní přistupovat do databáze objektově, resp. jedná se o ORM (Object Relation Mapping).
Ve světě C# má konkurenci v podobě projektu NHibernate (github, wiki), což je port Hibernate ze světa Javy. Zajímavé porovnání vyšlo v cz zde (je už ale neaktuální) :

• NHibernate nebo Entity Framework?

Kromě tedy usnadnění programování nám ORM i usnadňuje používání databází (není např. takový problém zmigrovat/nasadit projekt na jinou databázi jiného vendora).
Nevýhodou takového řešení je pak výkon, který je v určitých případech menší, ale to se dá řešit různými dalšími metodami. Příklad použití a nějaké další info např. zde :

• Fakturační systém v C# .NET - LocalDB a Entity Framework
• Proč nemám rád entity framework

Entity Framework (EF) vyvíjí Microsoft. Oracle musí pro EF připravit podporu. Je to tedy tak, že vyjde nový framework a pak se čeká, až Oracle vydá podporu ve svém klientu.
Poslední verzí EF je 6, která je tu s námi už pár let a další větší vývoj již údajně nebude. MS přislíbil jen podporu bugfixů a minor verzí. Nic víc. Poslední verzí je aktuálně EF 6.2 (26.10.2017)

Entity Framework Core (EF Core)

MS přepsal EF, který měl pak vyjít jako EF7, ale místo toho jej vydal jako EF Core (github). Stejně to udělal s ASP.NET (github). Výsledkem tedy je :

ASP.NET 5 -> ASP.NET Core 1.0
Entity Framework 7 -> Entity Framework Core 1.0

Každopádně EF Core nepodporuje všechny fce, které jsou v EF6, jedná se o odlehčenou verzi a vývoj jde asi jiným směrem, než byl v EF6.
Oficiální info je tu s námi od konce roku 2016 : Compare EF Core & EF6
Aktuálně tu je s námi ASP.NET Core 2.0 a EF Core 2.0.

• Portování z EF6 je zatím nepodporováno.
• Provoz EF6 s ASP.NET Core je možný.
• Přepis EF6 projektu do EF Core nemusí být aktuálně dobrý nápad.

Závěr

Určitě má toto malé shrnutí nějaké nedostatky, ale jako nástřel pro někoho by to mohl být dobrý začátek.

A jak jste na tom vy? V čem vyvíjíte? Používáte nějaké ORM, či nějaké frameworky?

Zdar Max
PS: doufám, že jsem někoho tímto zápisek ze světa MS moc neranil...

       

Komentáře

[Olík]

Gratuluji k převratnému vynálezu devops

[Max]

Nesouhlasím, to, na co poukazuji, není objevení DevOps, ale to, že DevOps zjevně nefunguje.
A já s tím můžu dělat dvě věci, buď za někoho budu dělat jeho práci, nebo toho někoho donutím si tu práci dělat tím, že to za něj prostě dělat nebudu :).
Zdar Max

[Pavel Riedl]

Třeba se to bude někomu hodit: Vyvíjíme také v kombinaci C#/Oracle. Pro přístup k db používáme už léta (10?) software od Devart. Je to malé a do releasu to přidá nějaké dll. Takže celou aplikaci rovnou zabalíme do ZIP archivu a distribuujeme. Samotná knihovna umožní jak přístup přes klasického Oracle Clienta, tak (námi používaný) Direct (není potřeba instalovat nic dalšího). Změna je pouze v připojovacích řetězcích.

[Josef Kufner]

Na tohle je dobré používat při vývoji continuous integration. Když vývojář musí dát dohromady build script, který vše poskládá a spustí v kontejneru na testovacím serveru, tak pak admin má dobrý návod jak to nasadit na produkčním serveru.

[Max]

V současné době probíhá vývoj tak, že se nasazují změny na produkci třeba i několikrát denně následující formou :
- něco se napíše
- otestuje se to na test prostředí
- nakopíruje se to na produkci pomocí Beyond Compare (tzn. nakopírují se rozdíly)
Vše toto dělají vývojáři.
Zdar Max

[Josef Kufner]

No… užijte si to.

Nasazení na testovací prostředí má být automatické po pushnutí do master větve (nebo jiné vyhrazené větve) a nasazení na produkci taktéž automatické, ale buď ručním stiskem jednoho čudlíku, nebo pushnutím do vyhrazené větve, kam má přístup jen vybraný člověk. Pokud tam je kdekoliv ruční zásah větší, než stisk toho jednoho čudlíku, tak s tím budou problémy. Ono vůbec spousta potíží se dá vyřešit odstraněním lidí.

A deploy na produkci několikrát denně? To musí být supr kvalitní software se spoustou nadšených uživatelů.

[Max]

Neřekl bych, že je to špatný sw, který by měl nějaké chyby, spíše se tlačí novinky do produkce.
Ale chápu, co tím myslíš (něco jako Jenkins, Chef apod.).
Zdar Max

[Odin]

Toto je totalni offtopic. Tezky drsny admin, ktery tady spamuje offtopic posty.

[Max]

Prohlašovat o blogu, že je offtopic, ty jsi buď velký joker, nebo jsi úplně mimo :).
Zdar Max

[Sněhulák]

U nás se vyvíjí v IntelliJ IDEA (skvělý soft), Javě (OK soft) s Oracle DB (horší soft). Bez ORM se lepí SQLka přímo v "controllerech" do stringů, někdy aspoň jako prepared queries, někdy přímo naprudko plusem Každý druhý tým má na to lepení SQLek vlastní pseudoframework, půlka logiky je implementovaná v DB procedurách a triggerech. Kusy SQLka se předávají mezi objektama, někdy se po cestě parsujou a žvýkají, hintujou podle pochybných heuristik apod. CI jakž takž funguje, jinak by se ten produkt rozpadl už dávno.

Naštěstí máme na lokální deployment pro devel účely virtuálky, takže si nemusíme PC zahnojit různýma pochybnýma knihovnama několika verzí. Taky používáme repository pro knihivny a artefakty, takže to dev nemusí shánět a stahovat někde sám, nedejbože instalovat. Takže aspoň něco

[deda.jabko]

Bez ORM se lepí SQLka přímo v "controllerech" do stringů

Na tom, ze se nepouziva ORM nevidim nic spatneho, ale chce to veskerou praci s daty peclive izolovat do jednoho mista. Je to sice ze zacatku narocnejsi na programovani, ale ma to i sve benefity, kdyz nekdo prijde s nejakym extravagantnim pozadavkem typu ukladani dat do ruznych NoSQL, klaudovych, in-memory ulozist.

Bez ORM

Nemuzu si pomoct, ale ORM mi sedi maximalne tak na jednoduche CRUD ulohy. Kdykoliv projekt zacal rust, prerustat sve puvodni urceni, zacalo ORM hazet klacky pod nohy. Tak jsem to zacal resit, jestli neco prece jen nedelam spatne a vzal si k tomu nekolik knih. Vetsina materialu by se dalo rozdelit do tri kategorii (1) autor nepochopil OOP, (2) autor nepochopil relacni databaze, (3) autor nechape OOP ani relacni databaze. Takze pokud to neni nezbytne nutne ORM se vyhybam, jak to jde.

[Josef Kufner]

Ono to klíčové je dobře udělat modelovou vrstvu. ORM je nízkoúrovňový nástroj mezi modelovou vrstvou a databází. Takže buď se postaví model nad ORM, nebo rovnou nad SQL, nebo (nejlépe) nad šikovným (a hloupým) query builderem nad SQL (query builder ušetří psaní a přitom tam není nic, co by házelo klacky pod nohy – dokud se query builder nesnaží být moc chytrý).

Spousta lidí si myslí, že ORM = model a pak je v controllerech kopec bordelu, který tam nemá co dělat a drobné změny jsou na týdny.

[dementni.lojzik]

dokud se query builder nesnaží být moc chytrý

soude podle toho mala co ja jsem videl, tak se casem stejne zjisti, ze je potreba to a tam to (treba lazy loading, caching ...) a driv nebo pozdeji to skonci vlastni implementaci Hibernatu, ktera se od nej lisi zejmena v tom, ze se s tim stravila hromada casu a je podstatne vic zabugovana

[K42]

Zlatý Oracle Forms

[Aleš]

Jsem neskutečně rád, že už něco podobného nemusím zažít ani jako vývojář.

V první řadě je dobré zmínit, že použití ORM, ať už v Jave či C# je jaksi na dlouho diskuzi, nicméně faktem je, že je určen pro středně velké projekty. Psát IS s ORM je dost zvláštní rozhodnutí.

Další věcí je, že dnes je rok 2018 a s tím souvisí i volba technologií, které jsou tomu poplatné. Díky tomu, že jsme před nedávnem začali na čistém listu papíru, tak jsme si mohli zvolit i technologie, které odpovídají dnešním dnům:

Typescript / Javascript, React, Node.JS, GraphQL, MongoDB

Co se týče nasazování, tak samozřejmostí je Cluster v Cloudu s Kubernetes, takže Docker apod. DevOps nemají co žrát :)

Pro CI je to CircleCI (GIT je samozřejmost).

Ve chvíli, kdy slyším věci jako: Oracle Driver, IIS, Weblogic, JPA, Entity Framework, JavaEE, ASP.NET, tak dostávám kopřivku. Nezbývá, než s těmito legacy projekty holt přežít následující desetiletí :)

[ijh]

Good luck s tím Mongem. Aspoň že máte typy v tom JavaScriptu (TS je fajn): pokud máte malý projekt, můžete to s nerelační DB pár let přežít.

Před pár lety podobný školní stacky (netypovaný jazyky, schemaless databáze) jely jako návody pro tvorbu enterprise aplikací a to bylo fakt nebezpečný. Je potřeba říct, že jakákoliv solidní Java / .NET má mnohem větší šanci vydělat peníze -- jakkoliv samozřejmě existují modernější možnosti. Haskell, Cassandra, nebo i Scala, F#.

[David]

Rad bych znal ty vyhody Node.js oproti Jave (Springu) nebo .net core pokud se teda nejedna o mini projektik na mesic.

[ehm]

Je to nejvíc cool a všichni to používají, tak to musí být dobré.

[MarlonB]

my pouzivame zatim stale ty stare nastroje, dnes uz nemoderni. Hlavu, tuzku, papir a tak. A taky mluvime se zakaznikem, co by jako chtel a hlavne potreboval. Zatim zadny z nasich zakazniku nepozadoval Angular, React, JavaScript, Git, Erlang, Rust, InteliIDDE, Java, Docker dokonce ani nikdo nechtel , aby se pouzival type safety jazyk a aby ten jazyk byl v navrhu takovy cisty.

Co ovsem zakaznici chteji je, abycom rozumneli jejich praci. Na to jsme jeste zadne IDE nenasli.

[ehm]

+1

[OldFrog {Ondra Nemecek}]

Jojo, vývojář by měl vědět, jak ten který systém funguje a měl by být schopný postavit kostru celé aplikace na zelené louce. Jenže ty nástroje jsou tak složité, v tolika verzích a s takovými souvislostmi, že je to dost náročné na zvládnutí. To pak vede k tomu, že vývojář skutečně něco používá ale vůbec netuší, jak to funguje, což je tedy dost špatný pocit.

Podle mě je skutečně asi jediným řešením cílené budování dokumentační báze (např. v podobě nějaké firemní wiki), kde se cíleně shromažďují všechna moudra, na které kdo přišel. Myslím, že taková kvalitní a napříč firmou sdílené know-how může být i dost motivující součástí firemní kultury.

BTW ono to platí i pro jednotlivce, že bez strukturovaných poznámek brzo člověk narazí na vlastí limity (nelze si zapamatovat všechno - už se mi dokonce stalo, že jsem řešil problém a na internetu nalezl jeho řešení, které - jsem postnul do nějaké diskuze já sám! - aniž bych si to pamatoval...).

[Max]

Pokud vezmu tento konkrétní případ, tak to zas tak složité není. Člověk si přečte dokumentaci, zjistí jaký je rozdíl mezi dvěma různými implementacemi, k dispozici je compatibility matrix co a jak křížit a je hotovo.
Toto může udělat jeden člověk a ostatní proškolit. Problém v mém případě byl, že to neudělal nikdo ze 3 vývojářů a musel jsem to řešit já, kdy už mi s nimi došly nervy při nasazování nové verze.
Zdar Max