Portál AbcLinuxu, 31. října 2024 23:53
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.
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á.
Š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.
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) :
Přesné rozdíly mezi Managed a UnManaged drivery popisuje Oracle zde :
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.
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" :
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 :
Je opět vedena u Oracle, viz Doc ID 726240.1 :
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)
ODAC OUI obsahuje :
2) Nasazení Runtime ke klientům
a) nasadit ODAC z nuget repositáře
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)
ODAC OUI obsahuje :c) použít ODAC XCopy pro rozsáhlejší nasazení :
ODAC XCopy obsahuje :
3) Oracle Client Full
Obsahuje úplně vše (včetně admin nástrojů apod.) kromě 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 :
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í.
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í) :
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.0Kaž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.
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...
Tiskni Sdílej:
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 ORMNemuzu 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.
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
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.