按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
know is her telephone number。 Translated into programming terms； the telephone acts as an
interface to an implementation。 The challenge is connecting to the implementation。 In the
case of the telephone； you can discover the telephone number by using the telephone book。
The telephone book contains the names of individuals at specific addresses and their tele
phone numbers。 Names and addresses are easy to remember； telephone numbers are a bit
more plicated。 Thus； the telephone book serves the purpose of cross…referencing an easy
piece of information with a more plicated piece of information。 In programming terms；
the cross…referencing is a configuration file that is associated with the application。 Once
you have cross…referenced the information； you have the location of the project and can then
instantiate the cross…referenced type。 In programming terms； the configuration file gives you
the location and name of the type。
Decoupling Using a Convention Architecture
Configuration files are useful； but they can bee too plicated。 Some projects have such
plicated configuration files that bugs arise due to an improperly configured application。
Convention architecture attempts to simplify plexity by instituting a familiar pattern
to the referencing of the type。 Consider a telephone number like 1…800…BIG…CARS。 The 1 and
800 are easy to remember； as is BIG CARS。 This works because of the convention where a digit
on the telephone keypad corresponds to three or four letters。 So in the case of BIG…CARS； the
number is 244…2277。
Conventions are good things as long as you know what they are。 For example； if you were
not familiar with the telephone system； you would wonder how BIG CARS represents a telephone
number。 The missing piece of information is the convention of how to convert the letters into
the numbers。
…………………………………………………………Page 338……………………………………………………………
316 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
What is useful with convention architecture is that you are not limited to what is defined
in the configuration file； as there is a general logic。 When implementing a convention architec
ture； you are not discarding configuration； but you are making assumptions for the user and
implementation of the code。 You will still probably have a configuration file； but the configuration
is for specific functionality。
Regardless of whether you use a configuration architecture or a convention architecture；
you will dynamically load assemblies； as demonstrated in this chapter。
Setting Up the Dynamic Loading Projects
For this chapter’s examples； four projects are defined：
o Definitions： A class library that contains the definition for the interface IDefinition and
the class ConfigurationLoader。 The class ConfigurationLoader will contain the functionality
to dynamically load the assemblies Implementations1 and Implementations2。
o Implementations1： A class library that contains the class Implementation and implements
the interface IDefinition。 The class Implementation is defined in the namespace
Implementations1 and is not declared Public。
o Implementations2： A class library that contains the class Implementation and imple
ments the interface IDefinition。 The class Implementation is defined in the namespace
Implementations2 and is not declared Public。
o CallRuntimeImplementation： A console application that will be referenced throughout
the chapter as the user application。
In the Definitions project； the references are to the standard libraries （ System；
System。Core； and so on）。 The unique reference that you need to add is to System。configuration。
The System。configuration reference contains the types that you need to read the application
configuration file。
Here is the code for IDefinition：
Public Interface IDefinition
Function TranslateWord（ByVal word As String） As String
End Interface
The Implementations1 project contains the file Implementation。vb； which is the type
Implementation and implements the interface IDefinitions。 The implementation of
Implementation is as follows （make sure you add a reference to the Definitions project）：
Imports Definitions
Class Implementation ： Implements IDefinition
Public Function TranslateWord（ByVal word As String） _
As String Implements IDefinition。TranslateWord
Return 〃〃
End Function
End Class
…………………………………………………………Page 339……………………………………………………………
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 317
The class Implementation has a hard reference to IDefinition； so under the References
node in the Implementations1 project is a reference to the Definitions project。 Because there
is a hard reference to IDefinition； the interface IDefinition is declared as Public； but
Implementation is not。
The Implementations2 project has the same implementation and reference to Definitions
as Implementations1。 What is special about Implementations2 is its use of a strong name； which
makes it unique。 Thus far； all of your assemblies are not unique。 To make them unique； you
need to enable signing。 You must also enable signing in the Definitions project。 The next
section describes how to enable signing。
The C