Game Development Reference
In-Depth Information
This architecture would work great in environments where numerous machines
need to use a particular tool, but issues and concerns with deployment and ver-
sioning present problems. Aside from the first client application and interface def-
inition installation, the only time the client machines would ever need an update
would be if the interface changed. If the interface definition were stored in a sep-
arate assembly, a simple push technology could be used to force all client machines
to remain up to date.
Conclusion
This topic discussed a certain way to design your .NET applications and libraries
so reusability and maintainability are promoted as much as possible.
There is really only one spot that cannot be independently developed at any time.
The Windows entry point in the example on the companion web site typically just
redirects standard input and output streams from the console entry point, helping
to reduce the amount of code to maintain both types of entry points. Because of
this, the Windows entry point cannot be developed before the console entry point
unless both are developed independently of each other. Thanks to the tool logic
residing in a separate module, no matter how you structure the entry points, you
only need to change the code in one spot to affect how the tool works everywhere. A
single module for the logic also helps with maintenance, versioning, and deployment.
As touched on with the alternative architecture described in this chapter, remoting
can be used as a barrier between all the entry points and the specific tool logic to
convert the architecture into a client and server design. The tool logic can reside
on one development server, and all client machines using the tool can access it
through a Remoted proxy object. Clients would just need the interface definition
the Remoted object implements, and the actual code can stay on the server. This
type of architecture would greatly improve deployment by only requiring a change
to the server code, and all clients would instantly start accessing the latest version.
Not all types of tools would benefit from this architecture, most notably any tool
that intensively accesses the local file system. However, if the server had share
access to each client, the tool could be designed to accommodate file system access
over the network.
The example overviewed in this topic is also available on the Companion Web site;
it shows how to structure an application with this architecture, and even how to
export a COM interface and register with Remoting. Keep in mind that these topics
are covered in much greater depth later in this topic, so no time will be spent
Search Nedrilad ::




Custom Search