-
GAMEPOD.hu
Új hozzászólás Aktív témák
-
dabadab
titán
válasz
akrobet
#9862
üzenetére
A feladatot jól megoldani nyilvánvalóan lehetetlen, csak hogy ez tiszta legyen
Nekem úgy tűnik, hogy így elsőre nagyon összekeverednek benned a rétegek, az alapvető rendszerarchitektúránál szinte nem isszámít az, hogy milyen nyelven csinálod az meg, hogy használsz-e reflectiont, az tényleg n+1. implementációs részlet.
Amit én hasonló témakörben láttam és nagyjából működik, az az, hogy az ember egyrészt az objektumoknál valami nagyon rugalmas adatmodellt használ (pl. gyengén típusos kulcs-adat párokat) és a döntéshozó részt kirakja scriptbe (mert az jóval rugalmasabb, mint amit adatbázisban tárolt szabályokkal meg lehet valósítani), így a "rendes" kódhoz csak akkor kell nyúlni, ha új funkcionalitás kell.
"Ha furcsa magyar megfogalmazást használok az azért van mert csak angolul tanultam programozást és nem tudom a magyar kifejezéseket."
Szerintem vagyunk így ezzel még páran
DRM is theft
-
dabadab
titán
válasz
akrobet
#9864
üzenetére
"Hogy lehetetlen jól megoldani, gondolom arra érted, hogy nincs elég információ a rendszer felhasználási mintájáról, adatforgalomról, fejlesztésre rendelkezésre álló időről stb..."
Nem, ezt arra értem, hogy egy olyan feladatot, ahol nem lehet érvényes modellt készíteni, mert bármit csinálsz, a következő változtatással felrúghatják valamelyik alapfelvetését, ott nem lehet olyan megoldást találni, ahol a változások követéséhez nem kell programozói munka.
"Mi lenne konkrétan a scriptben?"
Leírva az, amit akarnak, ilyenek:
if ( stuff.physical == true || stuff.type == "book" )
generate_comission"Én egy BusinessRule objektumra gondoltam ami valahogy így nézne ki:"
Ami rögtön meg is hal már abban az egyszerű esetben is, ha pl. két tulajdonságot kell egyszerre nézni.
[ Szerkesztve ]
DRM is theft
-
dabadab
titán
válasz
akrobet
#9869
üzenetére
"A scriptnek mi lenne az előnye hardcode-dal szemben azon kívül hogy nem kell a változtatásához egy release? Mert azt csak programozók tudnák úgy is megírni."
1. Egy helyen van a business logic. A hardcodedban szükségszerűen keveredik a business logic meg a mindenféle implementációs részlet, itt nem.
2. A fentiből adódóan sokkal egyszerűbb a kód.
3. Az ügyfélnél akár egy tehetségesebb IT-s is karban tudja tartani.
"Több rulet össze lehetne vonni egy BusinessRuleSet -be"
Ezzel megoldottál EGY problémát és máris megdupláztad az adatbázistábláid számát
De ha pl. ciklusra lenne szükséged, akkor megint nem tudsz azzal mit csinálni - és folyamatosan lehet találni ilyeneket addig, amíg vagy feladod, vagy Turing-kompletté válik a szabálykészleted és már meg is érkeztél a scripteléshez DRM is theft
-
bambano
titán
válasz
akrobet
#9862
üzenetére
szerintem itt két választási lehetőséged van:
1. ha igazi c# programozó vagy, mindent objektumnak nézel. ha ezt az elvet követed, nekifoghatsz, bele is fogsz fulladni és soha nem lesz kész.
2. fogsz valami, erre a feladatra normálisabb programozási nyelvet és adatbáziskezelőt, és megírod abban.nyilvánvalóan a második utat érdemes járni, mivel az első járhatatlan. a jó megoldás, hogy tervezni kell valami relatíve egyszerű nyelvet, esetleg véges automatát, ami boldogul a problémával, és annak az értelmezőjét leprogramozni. esetleg az adatbáziskezelő saját programozási nyelvében, akkor még relatíve gyors is lesz. szerintem ha jól eltalálod, hogy mit kell tudjon a nyelv, akkor 3-5 nap alatt meg lehet csinálni rendesen magát a szabályrendszert. a gui az más tészta
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
bambano
titán
válasz
akrobet
#9873
üzenetére
"Valahogy dinamikusan betölteni text file-ból a c# kódot?": szerintem c# forráskódot nem fogsz szövegből betölteni, de pl. lua interpretert nem olyan nagy durranás belevarrni egy java vagy c# programba. és a lua programot betöltheted adatbázisból is.
de szerintem nem jó ötlet egy teljesen általános programnyelvet használni erre a specifikus feladatra.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
dabadab
titán
válasz
akrobet
#9873
üzenetére
"Valahogy dinamikusan betölteni text file-ból a c# kódot?"
A C# nem scriptnyelv - meg bár létezik némileg módosított, scriptelős változata is, de nem vagyok biztos abban, hogy bölcs lenne egy ennyire túldizájnolt nyelvet használni ilyen viszonylag egyszerű feladatra.
Ez úgy működik, hogy fogsz egy scriptengine-t (mondjuk Pythont vagy Luát), belerakod a kódodba, a konkrét scriptengine-től függő módon összekötöd a scriptet a fordított kódoddal és készen is vagy
DRM is theft
-
bambano
titán
válasz
akrobet
#9878
üzenetére
rendben, akkor találj ki egy programozási nyelvet, aminek az értelmezőjét c#-ban írod meg. én phpban írnám, mert igazán nagyon durvát szerintem abban lehet kavarni, de ha neked c# kell, nem gond.
ha az értelmezőt c#-ban írod, akkor le fog fordulni és működni fog további függőség nélkül."Továbbá a kiindulási helyzet is az, hogy már adott a rendszer többi része, tehát valószínűleg késő lenne egy új programozási nyelvet "feltalálni" és az adatbáziskezelőt lecserélni.": az adatbáziskezelő lehet jó vagy rossz korlátozó tényező, de ha csak adatbázison keresztül kommunikálna a rendszer, akkor nem lenne gond, hogy más nyelvű modulokat faragj mellé.
"Namármost, ha én olyan szinten lennék (de nem vagyok) hogy írjak egy új nyelvet, amiben ezeket a szabályokat kellene írni, attól még nem szűnne meg a szükség a maintenance-re": ha az értelmezőt nem kell módosítani, akkor a kódot emiatt nem kell karbantartani, így az a fajta karbantartás nincs, ami akkor lenne, ha kódba vésnéd a logikát. a szabályrendszer karbantartását meg, szerintem, meg lehetne egyszerűen oldani, ha jól megmakrózod az egészet.
nem olyan nagy durranás, régi ibm gépeket assemblyben programozták, mert a makro assemblere mocskos jól volt megfaragva.
hasonlót, kicsit kisebb léptékben, csináltam magamnak nemrég, megvolt egy nem alvós hétvége alatt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
válasz
akrobet
#9878
üzenetére
Szerintem a többiek ezt a C# ellenességet túllihegik, pontosabban félreértik, mivel a feladatot sokkal inkább SQL oldalon kell szerintem megoldani, mintsem C# oldalon. Ha adatbázisban jó, rugalmas és gyors modellt tudsz felépíteni, akkor azt kezelni már teljesen mindegy, hogy milyen nyelvben fogod.
És ugyanez igaz fordítva is. Ha db szinten elcseszed, na akkor egy szuper rugalmas PHP se ment meg attól, hogy le ne fosd a bokádat nap, mint nap a szabályok átdrótozásakor.
Én ugyan NoSQL-el állnék neki, de hiszem, hogy hagyományos SQL-el is jól megfogható a probléma, pl. raktam már össze repülőjegy árazó engine-t, aminek kellemesen bonyolult sok dimenziós mátrixokból kellett dolgoznia, és szépen megoldható volt sima SQL-el, 3-4 táblával, meg némi C#-al a DB felett.Én kérek elnézést!
-
amargo
addikt
válasz
akrobet
#9878
üzenetére
en xml be kezelnem le a problemat es abbol expression segitsegevel generalnam a kodot szerver oldalon. egyszeruen azert xml, mert xml-ul barki tud es kelloen rugalmas a szabalyok leirasara.
viszont lassabb lesz barmilyen nativ megoldasnal. de gyors es rugalmas is egyszerre nem tudom, hogy lehetne. nyilvan egy erre kulon letrehozott feldolgozoval, amit mar tobben is javasoltak meglehet oldani. de szerintem itt nem ez az elvaras.“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
bambano
titán
válasz
akrobet
#9885
üzenetére
"Számomra az is fura olvasni olyan érvelést, hogy valamit milyen kevés sor kódból lehet megírni..": az érvelésem lényege, hogy ha lényegesen több sorból hozod össze, akkor valamit túlbonyolítottál, tehát nem fog sikerülni.
"entity framework-kel": itt szoktak elbonyolódni a dolgok, mikor bejön a framework framework hátán
ne hidd, hogy egy tömör, sima kódot nehezebb olvasni, mint egy agyonframework-özött kódot. php-ben behúzol egy táblát két sorban, ugyanez egy perzisztencia réteggel külön osztályhegyeket igényel.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
válasz
akrobet
#9885
üzenetére
"bármilyen business logic SQL-ben való megírása teljes no-go, mert szinte lehetetlen karbantartani, tesztelni, stb.
amikor netán valami elcseszett adatotra kell SQL-ben scriptet írnom, az egy kész kínzás .NET kódhoz képest ahol kb. az 1/50-e idő alatt megírom azt amit akarok, linq-el, entity framework-kel"Hopp, na akkor itt valóban a szó legrosszabb értelmében vett igazi C# fejlesztővel állunk szembe. Be kell lássam bambanonek, tökéletesen igaza volt.
Gondoltam rákérdezek, hogy miért lehetetlen SQL-ben megírva bármit is karbantartani, pláne tesztelni? Jó, nyilván nem olyan triviális, mint szimplán C# kódot tesztelni, de ezt így kijelenteni, hogy lehetetlen?![;]](//cdn.rios.hu/dl/s/v1.gif)
Hidd el egy idő után az a leglényegtelenebb, hogy C#-ban 1/50-ed idő alatt írsz-e meg valamit, ha elkezditek a többedik SQL clustert alátolni a szarul megírt kódnak, ahelyett, hogy némi logika SQL oldalon is lenne."C# fejlesztőként" biztos nehéz elképzelni, de attól még, hogy üzleti logika van SQL-ben, a kód olvashatóság semmit nem romlik, no persze az nem árt, ha valaki konyít az SQL-hez. Ez ugyanolyan, mint ha azt a hülyeséget mondanám, hogy attól romlik a kód olvashatóság, hogy webfejlesztéshez nem átallok javascriptet, sőt css-t is használni, nem pedig tisztán C#-ban /PHP-ban írok meg mindent.
Én kérek elnézést!
-
válasz
akrobet
#9893
üzenetére
Én sose értettem, hogy miért jó az "univerzális" adatbázis nagyobb rendszerek esetén. Ha képlékeny még, hogy milyen DB kell, akkor még talán megértem, de ennyi erővel meg lehet, hogy a C#-ot kell dobni. A SQL -> noSQL váltási kényszer belekalkulálását meg aztán végképp baromságnak tartom, nagyon másra való a kettő. Egy esetleges DB migrációra fel lehet ugyan valamennyire készülni (ha előre tudod, hogy lesz), de az egy worst-case scenario, emiatt eltoszni a kódot butaság.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
válasz
akrobet
#9898
üzenetére
De ez akkor a fejlesztés része, ez megint más, ideiglenesen kb abban írod amiben akarod, a kész szoftvernél meg már fix DB lesz, az ami a legjobb a feladatra. Ám lehet inkább alaposan körül kéne járni és megtervezni a DB kérdést, nem pedig rögtön elkezdeni írni ész nélkül, amikor még azt se tudod hogyan lesz.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
martonx
veterán
válasz
akrobet
#9893
üzenetére
"De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?" - ok tegye fel a kezét, aki naponta vált MS SQL-ről Oracle-re és vissza
SQL - NoSQL pedig még ORM-el sem átjárható, mivel teljesen más szemléletmódot, felhasználást várnak el.
Egy programnál mindig el kell dönteni, hogy milyen infrastruktúrán fog futni, és utána abból kihozni a legjobbat. Tipikus félreértés, hogy az ORM azért jó, mert elfedi a DB layert, és könnyű átjárhatóságot biztosít (az meg még nagyobb félreértés, hogy SQL - NoSQL átjárhatóságot is biztosítana). Mármint az átjárhatóság SQL-en belül még nagyjából igaz is, de ennek csak akkor van szerepe, ha az ember tudatosan, direkt pont olyan rendszert fejleszt, amit kb. bárhova el akar adni, és célja, hogy Oracle, MySql, PostgeSQL, MS Sql, bármilyen SQL felett tudjon működni a rendszere. Ebben az esetben némi plusz munkával valóban meg lehet írni ORM-el úgy a rendszert, hogy az tökéletesen átjárható legyen.
ORM-et elsősorban inkább azért használunk, mert kényelmes vele dolgozni, a kód valóban olvashatóbb lesz tőle, de fontos, hogy folyamatosan tartsuk szem előtt, hogy az ORM csak egy eszköz, és nagyon könnyen hibás architektúrákhoz vezethet, ha csak és kizárólag egy ORM-re alapozva fejlesztünk. Erre tökéletes példák vagytok ti.Ez az SQL-ben legyen logika dolog teljesen eset függő, nincs rá jó válasz. Én az általad megfogalmazott problémával kapcsolatban mondtam, hogy ebben az esetben szerintem tipikusan sokkal jobb megoldás tud lenni, ha komolyabban az SQL-re bízná magát az ember, és komolyabban elgondolkodna az SQL-ben való adatmodellezésen (nem is feltétlenül érdemi logikának kellene talán az SQL-ben lenni, egyszerűen csak végre komolyabban kellene gondolni, tervezni az SQL oldalon is a tábla struktúrákat, amikkel a várt dinamikus szabály rendszert könnyen lehetne modellezni, majd azt utána C# oldalon felhasználni).
Pláne amikor későbbi hszediből ki is derült, hogy a DB-t tényleg ahogy esik, úgy puffan alapon használjátok, szóval egyre biztosabb vagyok a meglátásom helyességében.
Szóval nem akarok olyan erős kijelentéseket tenni, hogy csak így, vagy csak úgy a jó, az elmúlt pár évben mindkét megoldást használtam, mindig azt amire éppen az adott esetben szükség volt.Főállásomban pont az elmúlt években volt / van egy ilyen komolyabb szemléletváltás, amikor az eredetileg mindent EF-el oldjunk meg, és kapja meg az adatot a C#, aztán majd abban jobban feldolgozzuk szemléletet a több milliárd adatsoros tábláknál már fel kellett, hogy váltsa az "oké, akkor amit lehet SQL oldalon oldjunk meg, de azért amit nem muszáj, az menjen továbbra is EF-el" szemlélet. Hidd el, pont ugyanúgy lehet mindent tesztelni SQL felhasználása mellett is, csak mondjuk egy teszt nem 5 másodpercig fog futni, hanem fél percig. De ha elég jól párhuzamosítod őket, akkor végül időben se tart feltétlenül tovább.
Minden csak hozzáállás kérdése, még az általad felvázolt alapvetően hibásnak tűnő architektúra is valószínűleg tesztelhető maradna némi refaktorálás után, megfelelő mockolásokkal.Én kérek elnézést!
-
bambano
titán
válasz
akrobet
#9893
üzenetére
nem tudok elképzelni olyan helyet, ahol mssql-t ne lehetne találni. tehát ha szolgáltatót is kell váltani, adatbázismotort nemigen.
másrészt ha nosql-re kellene váltanod, ott a legkisebb problémád lesz az, hogy pár eljárás volt az sql motorban. sql-ről nosql-re váltani az kb. a komplett alkalmazás újratervezését jelenti."Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...": itt nem arról van szó, hogy az egészet tedd procedurális sql-be, hanem arról, hogy azt az egy problémát, amivel a threadet elindítottad, azt tedd ilyenbe.
nekem vannak kétségeim, hogy jól van-e tervezve az az adatbázis, amiben 15+ level mélységű relációk vannak, különös tekintettel a view-ekre...
"nagyon hamar el fog menni tőle a kedved": ezt a szempontot nem annyira szokták figyelembe venni... nekem pl. a felvételi elbeszélgetésen elmenne a kedvem, ha mssql-ről esne szó
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Megérkezett a Google Pixel 7 és 7 Pro
- ASZTALI GÉP / ALKATRÉSZ beárazás
- Tenisz topic
- 5.1, 7.1 és gamer fejhallgatók
- Kés topik
- Melyik tápegységet vegyem?
- Kormányok / autós szimulátorok topicja
- Google Pixel 7a - venni vagy nem venni?
- Vigneau interaktív lokálblogja
- Jack Hunter: Egérragasztó
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- Telefon felváráslás!! Samsung Galaxy S22/Samsung Galaxy S22+/Samsung Galaxy S22 Ultra
- Gyönyörű Huawei P10 Kék színben Új akksival és fóliás kijelzővel + bontatlan Mashup Case
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen