Information Technology Reference
In-Depth Information
entire new application, I'll discuss a variety of enhancements to the
dynamic CSV class from Item 44. You need to determine if the new fea-
tures belong with the core capabilities you've already delivered, or if it's an
option that a smaller set of your users will appreciate. The version I created
returns all data in the CSV file as strings. You could create adapters that
would convert the strings to numeric values when the column supported
it. That would probably be something that most users would want. Those
adapters should be in the same assembly. Another addition might be sup-
porting more than one level of headers. That would enable nested head-
ers, like Excel pivot tables. That feels like something you'd put into a
different assembly. Only some of your users would use that feature. The
most common usage would be the version containing the single headers.
That means it makes the most sense to put the multiple header function-
ality in a different assembly. It may depend on the core assembly, but it
should not be in the same location.
What about internationalization? That one doesn't have a simple answer.
Yo u m a y b e c r e a t i n g a p p l i c a t i o n s f o r m u l t i n a t i o n a l e n t e r p r i s e s , a n d m u l -
tiple language support is critical for everyone. Or, you may be writing a
simple utility for local soccer leagues. Or, your expected audience could
be anywhere in between. If most of your users will be in one language,
whatever that might be, separating multiple languages into a separate
assembly (or even one assembly per language) might make sense. On the
other hand, if your user base will often need to use CSV files in a variety
of languages, multiple languages should be part of the core functionality.
Yo u n e e d t o d e c i d e i f t h i s n e w f u n c t i o n a l i t y i s g o i n g t o b e u s e f u l t o a n
overwhelming majority of users for your core functionality. If it is, then
you should add the new functionality to the same assembly. On the other
hand, if this new functionality is expected to be used only in some of the
more complicated examples, then you should separate that functionality
into a separate deliverable unit.
Second, using multiple assemblies makes a number of different deploy-
ment options easier. Consider a three-tiered application, in which part of
the application runs as a smart client and part of the application runs on
the server. You supply some validation rules on the client so that users get
feedback as they enter or edit data. You replicate those rules on the server
and combine them with other rules to provide more robust validation.
The complete set of business rules is implemented at the server, and only
a subset is maintained at each client.
