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

[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