VB2008从入门到精通(PDF格式英文版)-第97部分

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！



of　type　IDefinition。　

　　　　　Is　it　correct　to　assume　that　the　dynamic　loading　of　a　type　can　fulfill　the　contract　of　DoIt（）？　　

Can　you　assume　that　the　type　even　supports　IDefinition？　

　　　　　What　convention　over　configuration　attempts　to　do　is　create　pockets　of　self…contained　　

functionality　that　can　take　care　of　themselves。　That　self…contained　functionality　may　require　　

configuration　file　settings；　and　it　may　require　other　assemblies。　But　what　it　does　not　require　is　　

a　directive　that　includes　source　code　that　explicitly　states　what　to　do　when。　　

　　　　　Consider　a　workplace　scenario。　Instead　of　having　a　manager　tell　the　workers　what　to　do　at　　

every　step；　a　certain　amount　of　peer…to…peer　intelligence　and　self…reliance　are　assumed。　The　　

self…reliance　is　both　good　and　bad。　It　is　good　in　that　there　are　fewer　moving　parts；　but　bad　in　　

that　the　peers　might　be　doing　something　that　they　should　not。　

　　　　　The　following　code　shows　an　example　of　convention。　



Interface　Imand　　

　　　　Sub　Run（）　

End　Interface　

。　。　。　

ConfigurationLoader。Instance。Load（）　

Dim　definition　As　IDefinition　=　_　

　　ConfigurationLoader。Instance。Instantiate（Of　Imand）（〃Impl1〃）　

definition。Run（）　


…………………………………………………………Page　360……………………………………………………………

338　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　A　R　N　I　N　G　　　A　B　OU　T　　　A　PP　L　I　CA　TI　O　N　　　CO　N　F　I　G　U　R　AT　IO　N　　　AN　D　　　D　Y　N　A　M　I　C　　L　O　AD　I　N　G　



　　　　　　　　　　　　　　　　The　code　runs　some　other　code　via　the　Run（）　method　and　does　not　have　any　return　values　　

　　　　　　　　　　　or　parameters。　The　code　doing　the　executing　is　hoping　that　everything　will　work　out；　because　　

　　　　　　　　　　it　cannot　check　a　return　value。　And　that　is　the　gist　of　convention　over　configuration—the　　

　　　　　　　　　　　calling　code　hopes　everything　will　work　out。　　

　　　　　　　　　　　　　　　　For　the　most　part；　convention　works　out　quite　nicely　because　it　is　easier　to　extend　and　　

　　　　　　　　　　maintain　a　convention…based　system；　since　there　are　fewer　moving　parts。　For　any　plex　　

　　　　　　　　　　　system；　the　fewer　moving　parts　the　better。　The　downside　is　that　the　administrator　needs　to　　

　　　　　　　　　　understand　what　the　moving　parts　are。　　

　　　　　　　　　　　　　　　　People　have　a　tendency　to　make　everything　configurable　and　leave　nothing　to　the　puter　　

　　　　　　　　　　program。　Whether　or　not　something　works　depends　on　how　the　configuration　is　written。　In　　

　　　　　　　　　　　a　convention　architecture；　the　called　functionality　will　make　decisions　about　what　it　deems　　

　　　　　　　　　　　appropriate。　

　　　　　　　　　　　　　　　　Here　is　an　example　of　configuration：　



　　　　　　　　　　　　　　　_　

　　　　　　　　　　　　　　Public　Property　TypeName（）　As　String　

　　　　　　　　　　　　　　　　　　Get　　

　　　　　　　　　　　　　　　　　　　　　　Return　CStr（MyBase。Item（_propTypeName））　

　　　　　　　　　　　　　　　　　　End　Get　

　　　　　　　　　　　　　　End　Property　



　　　　　　　　　　　　　　　　The　code　should　look　familiar；　as　it　reassembles　the　configuration　code　you　saw　earlier。　　

　　　　　　　　　　But　this　code　is　overconstrained　and　requires　too　many　moving　parts。　It　would　be　great　to　　

　　　　　　　　　　　simplify　it　to　the　following　code　（which　does　not　pile　because　you　cannot　change　the　code　　

　　　　　　　　　　base　of　the　　library）。　



　　　　　　　　　　　　　　　_　

　　　　　　　　　　　　　　Public　ReadOnly　Property　TypeName（）　As　String　

　　　　　　　　　　　　　　　　　　Get　　

　　　　　　　　　　　　　　　　　　　　　　Return　CStr（MyBase。Item（_propTypeName））　

　　　　　　　　　　　　　　　　　　End　Get　

　　　　　　　　　　　　　　End　Property　



　　　　　　　　　　　　　　　　The　difference　between　the　two　code　pieces　is　the　missing　parameters　in　the　　attributes。　　

　　　　　　　　　　The　parameters　are　not　necessary　because　they　are　already　defined　by　the　data　member　　

　　　　　　　　　　_propTypeName；　and　you　can　use　the　identifier　of　the　property　as　that　extra　piece　of　informa

　　　　　　　　　　tion。　So　the　property　identifier　TypeName　could　be　used　as　an　identifier　for　an　XML　attribute。　

　　　　　　　　　　　　　　　　Some　may　argue　that　by　having　a　cross…reference　between　the　property　identifier　and　　

　　　　　　　　　　　configuration　identifier；　you　are　creating　a　hard…coded　dependency。　That’s　a　valid　argument。　　

　　　　　　　　　　But　is　the　code’s　assumption　a　mon…sense　assumption？　Is　it　an　extreme　proposition　to　say　　

　　　　　　　　　　that　your　property　identifier　is　the　name　of　your　XML　attribute？　The　answer　is　that　it　is　not　an　　

　　　　　　　　　　　extreme　proposition；　and　the　Ruby　on　Rails　creators　said　the　same　when　creating　their　own　　

　　　　　　　　　　　architecture。　

　　　　　　　　　　　　　　　　Let’s　now　consider　the　ability　to　indicate　whether　a　configuration　item　is　required。　By　　

　　　　　　　　　　　specifying　whether　or　not　an　attribute　is　required；　you　can　avoid　an　exception　at　a　later　point。　　

　　　　　　　　　　However；　think　about　the　bigger　context。　The　　IsRequired　attribute　is　processed　when　the　　

　　　　　　　　　　program　is　started。　The　validity　of　the　configuration　file　is　not　processed　at　pile　time；　and　　

　　　　　　　　　　thus　the　only　thing　that　IsRequired　does　is　generate　an　exception　earlier。　Maybe　you　want　to　　

　　　　　　　　　　　avoid　any　runtime　errors　that　could　bring　down　a　program　during　processing。　I　don’t　think　it　is　　


…………………………………………………………Page　361……………………………………………………………

　　　　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　AP　P　L　I　CAT　I　ON　　　CO　N　F　IG　U　R　AT　IO　N　　　A　N　D　　　D　Y　N　A　M　IC　　　L　O　AD　IN　G　339　



a　big　advantage；　but　I　am　sure　others　will　think　it　is；　and　thus　using　the　IsRequired　property　　

is　a　judgment　call。　　



■Note　　The　aim　of　convention…based　architecture　is　to　make　as　many　assumptions　as　possible；　without　　

sacrificing　the　bigger　goal　of　the　application。　A　good　convention…based　architecture　is　not　easy　to　create　　

because　it　requires　pletely　understanding　the　needs　of　the　developers　and　those　who　run　the　application。　　

My　personal　rule　of　thumb　is　to　solve　the　problem　first；　and　then　decide　what　should　be　configured　and　what　　

should　be　a　convention。　



Dynamically　Loading　Base　Class　or　　

Interface　Types　



This　chapter　demonstrated　two　categories　of　code　that　were　dynamically　loaded。　The　first　cate

gory　was　a　type　that　implemented　an　interface　（Implementation　and　IDefinition）。　The　second　　

type　was　a　class　that　subclassed　another　class　（　LoaderSection；　ConfigurationSection）。　Each　　

approach　has　its　advantages　and　disadvantages；　but　there　is　a　single　rule　that　you　can　use。　

　　　　　Whether　to　use　an　interface　or　class　depends　on　how　much　responsibility　you　want　to　　

delegate　to　the　implementation。　In　the　configuration　processing　example；　the　　infrastructure　　

specifically　indicated　that　the　only　responsibility　of　the　dynamically　loaded　class　is　to　indicate　　

which　identifiers　should　be　processed。　How　the　value　of　the　identifiers　are　extracted　and　converted　　

into　　types　is　the　responsibility　of　the　base　class。　

　　　　　When　you　instantiate　a　type　and　use　an　interface；　you　are　delegating　plete　control　to　　

the　dynamically　instantiated　type。　The　calling　code　is　explicitly　saying；　“Here　is　your　contract。　　

How　you　deal　with　it　is　your　responsibility。　Just　make　sure　to　implement　the　contract　properly。”　　

By　delegating　all　the　responsibility；　you　are；　in　a　sense；　asking　for　trouble；　because　developers　　

might　implement　a　contract　incorrectly。　



The　Important　Stuff　to　Remember　



In　this　chapter；　you　learned　about　configuring　an　application　and　dynamically　loading　code　　

that　is　executed。　The　main　items　to　remember　are　as　follows：　



　　　　　o　　A　　application　configuration　file　works　only　because　there　is　code　in　the　application　　

　　　　　　　　that　uses　the　specified　items　in　the　configuration　file。　　



　　　　　o　　Applications　have　　application　configuration　files　where　the　name　of　the　file　is　the　　

　　　　　　　　name　of　the　executing　application　appended　with　a　　。config。　



　　　　　o　　A　　application　configuration　file　is　a　specially　formatted　XML　file。　



　　　　　o　　A　　application　configuration　file　applies　to　a　specific　assembly　loaded　by　the　　

　　　　　　　　application。　



　　　　　o　　The　default　scenario　for　a　　application　configuration　file　is　to　store　the　settings　as　　

　　　　　　　　key/value　pairs　in　the　　section。　


…………………………………………………………Page　362……………………………………………………………

340　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　A　R　N　I　N　G　　　A　B　OU　T　　　A　PP　L　I　CA　TI　O　N　　　CO　N　F　I　G　U　R　AT　IO　N　　　AN　D　　　D　Y　N　A　M　I　C　　L　O　AD　I　N　G　



　　　　　　　　　　　　　　　o　　You　can　enhance　the　　application　configuration　file；　but　that　implies　implementing　　

　　　　　　　　　　　　　　　　　　types　that　specifically　outline　which　XML　nodes　and　attributes　are　to　be　present　in　the　XML。　



　　　　　　　　　　　　　　　o　　When　processing　data；　you　sometimes　need　a　type　（such　as　ConfigurationInfo）　that　is　　

　　　　　　　　　　　　　　　　　　used　to　store　information　in　a　structured　manner　for　a　specific　reason。　　



　　　　　　　　　　　　　　　o　　　has　plenty　of　functionality　that　allows　a　developer　to　dynamically　execute　code。　



　　　　　　　　　　　　　　　o　　One　way　of　dynamically　executing　code　is　to　load　an　assembly；　instantiate　a　type；　and　　

　　　　　　　　　　　　　　　　　　then　cast　the　instance　to　a　specific　known　type。　



　　　　　　　　　　　　　　　o　　You　can　instantiate　private　types　declared　in　an　assembly。　



　　　　　　　　　　　　　　　o　　You　can　use　the　GAC　to　store　assemblies　that　will　be　shared　by　multiple　applications。　



　　　　　　　　　　　　　　　o　　Use　the　GAC　only　if　you　must。　If　you　do　use　the　GAC；　you　need　to　create　strongly　named　　

　　　　　　　　　　　　　　　　　　assemblies　using　signing。　



　　　　　　　　　　　　　　　o　　Regardless　of　how　an　assembly　is　versioned；　a　version　number　should　exist　and　be　used。　



　　　　　　　　　　　　　　　o　　In　convention…based　coding；　your　code　makes　assumptions　about　its　behavior。　　

　　　　　　　　　　　　　　　　　　Convention…based　coding　is　more　pact；　but　because　assumptions　are　made；　the　　

　　　　　　　　　　　　　　　　　　code　is　less　flexible。　However；　do　not　confuse　flexibility　with　being　the　best　way　to　do　　

　　　　　　　　　　　　　　　　　　something。　You　should　have　flexible　code　when　you　need　it；　not　just　because　it　can　be　　

　　　　　　　　　　　　　　　　　　written　that　way。　



　　　　　　　　　　　Some　Things　for　You　to　Do　



　　　　　　　　　　　The　following　are　some　exercises　for　you　to　do　to　apply　what　you’ve　learned　in　this　chapter。　



　　　　　　　　　　　　　　　　1。　　Rewrite　the　configuration