按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 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。
…………………………………………………………Pag