Tegyük fel emailt akarok küldeni egy weboldalról, amiben linkekeket kell elhelyezni, amik hivatkoznak a weboldal urljeire.
Az email generálás a business logic jellegű komponensekben van. Ezeknek nem illik kinyúlkálni HttpContextekbe meg mindenféle webes cuccokba, mert ők nem webes cuccok. De ebben az esetben mégis csak fel kéne dinamikusan deríteni, hol fut a webapp, mert urleket kell generálni.
Ha kézzel passzolom át a szükséges infót, így néz ki a hívási lánc:
ArticleController.ArticleEdit => (innentől BBL, nem web) IArticleManager.UpdateArticle => INotificationManager.ArticleModified => INotificationFormatter.SendNotification
Na, a NotificationFormatternek már tudni kell urleket gyártani, a felette futó website intrinsic property-jei alapján.
Ezt kézzel átpasszolni a teljes láncon ronda. Mi jöhet még szóba? Statikus változók, amit a webapp indulásakor pl. a global.asaxben feltöltök, és a BLL-ben kiolvasom? Nem tetszik, de egyszerű. Utálom a statikusokat, szétborítanak minden tesztet.
Létrehozni egy IWebEnvironment interfészt, amit a tesztekben fake-elek, élőben pedig szintén a web indulásakor betárazok a DI containerbe? Kicsit körmönfont, de ez egy fokkal jobban tetszik.
Ötlet?
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
6 COMMENTS
Én a Spoke-Hub paradigmát javaslom :)
btw. egy sima dictionary?
Nem, nem dictionary, az mindig rosszra csabit. Inkabb egy celobjektum, limitalt propertykkel. A dictionary mindig ott hordozza a lehetoseget, hogy meg ezt is rakjuk bele, meg azt is, a vegen pedig ott van egy huszmegas szorny. Ha minden egyes dontes egy uj property bevezetesevel jar, akkor csak arra hasznalod, amire tenylegesen valo.
Ha valaki 20 megát szállít egy dictionaryban, az megérdemli. Az erősen tipusosság itt szerintem túl rugalmatlan. Amúgy is a világ a dinamikus tipusosság felé tendál. A .NET-es technológiák is tele vannak namevaluecollectionnel, speciel az asp.net is. Nincs a dictionaryval semmi gond, jól kell használni. Azt szokták mondani, hogy az adatok küldése oldalán legyél konzervatív, a fogadás oldalon pedig liberális.
Esetleg valami template nyelv szeruseg? Ertem ezalatt, hogy level torzsben minden linknel a website resz mondjuk [[]] koze lenne teve es egy szimbolummal elnevezve, amikor elkeszul eloszor a level. A kesobbi retegek belekurkasznanak a levelbe es lecserelnek ezeket a template szimbolumokat. Ez is megserti a retegek fuggetlensegenek elvet mondjuk, de nekem megis jobban tetszik. Mondjuk az objektum amit passzolsz lehet intelligens, pl leszarmazottja a System.Net.Mail.MailMessage-nek, es kiterjesztheted egy extra fuggvennyel, pl ApplyWebAddressesInBody vagy ilyesmi, ez vegezne el a template lecserelest. Feltetelezem, hogy egy ilyen objektum bugyborekol egeszen addig a kodig, ahol a System.Net.Mail.SmtpClient felkonfiguralodik (smtp szerver name-el, stb), es arra hivsz egy Send-et, aminek a bemeneti parametere ez a MailMessage payload. Ez gyakorlatilag majdnem teljesen tiszta .NET-es interface. A MailMessage leszarmazott objetumod meg egy kicsit alakitana a Body-t (sajat magan belul) amikor eler ahhoz a reteghez, aminek birtokaban van az informacio. Mi a velemeny?
Csaba: template-es a levél szövegének generálása. A kérdés itt az, hogy van egy host enviromentre jellemző infó, ezt kellene eljuttatni szépen egy mélyen az alsóbb rétegekben működő komponensnek.
A levélben szükséges infó a legfelső rétegben, a webesben van.
A gyakorlati megvalósításban egyébként az IWebEnvironment-es megoldást használtam végül.