I am looking for better concrete examples, as I am a bit dense, on design
patterns that facilitate my goals. I have been out to the code project,
planet source code, and microsoft's patterns and practices site and it just
isn't sinking in all that clearly to me.
Currently we have code in production and it all works well, however it is
not the way we want it. We know that we can implement a better design plan
to improve performance, readability, and enhancements.
We started out as a prototype for discovery, modeling after an existing
mainframe application and set of job streams. Expectations were set on the
application behaving as the old program did, and now the business wants to
take advantage of what the "PC" world has to offer in smart clients, web
services, bi reporting and the like.
Feel free to correct any false assumptions in this post as I get to each of
my questions.
First, we are currently using SQL Server 2000 because our document
management solution is bound to it and the company doesn't want to have two
SQL environments until the document management solution also supports SQL '05
(due out this fall.).
One of our main goals is to replace the need for our Citrix and Terminal
Server farms. Some of our internal folks will still connect in this manner,
however remote offices and sales/service folks will make use of
disconnected/web based front-ends.
Our data must maintain a historical audit, preserving what it looked like at
any given point in time. Changes occur in the form of "Corrections" or
"Transactions". Corrections are non-volatile changes to the data that imply
this is how the data should have been. Transactions consist of any change
that occurs and impacts legal or monetary conditions.
Basically, we do not delete, or update rows, rather we version our data.
The data itself consists of basically a "Contracts" table and its elemental
sub tables. There are other entity tables for vendors, producers, and a
variety of lookup tables.
Essentially, the company is services based company and two elements of a
contract contain information that requires a calculation for determining a
price towards the contract. There are commonalities between these items,
and we attempted to generalize the calculation logic to allow us to work
with either element.
Currently, the main application is a windows forms program. We have
separated the core business logic and data interaction in it's own dll
project, and use it in our batch processing and reporting programs. It is
up to the programs to validate data were possible, otherwise, and hopefully,
our database catches the remaining issues.
The business library consists of a master class, used as a singleton, to
manage interaction with the rest of the library. It fetches list data in
the form or data tables, or binding lists. Creates either an instance of a
new contract or reconstitutes an existing contract. It manages the state
and condition of the contract, which seems to get hairy at times. Sub
elements of the contract are presented as a bindinglist(of T).
Each entity derives from two base classes, BaseEntity and BaseEntityDetail.
BaseEntity represents a place holder for a single row of data.
BaseEntityDetail represents all the detail attributes for each "version"
change of the entity. This is also the construct in the SQL database, a
parent entity table and its entity details table.
Among my issues, the state of the data becomes confused, the user interface
can get into an unstable state, and sometimes information is not written to
the database without error. Finally, with 5 developers on the team, there
are times when new features break existing functionality and are not
discovered until long after release.
I apologize for the long preface just to get to my questions. Please bear
with me.
What I am looking for is a better way to manage my data, a better way to
manage my business logic, a better way to implement my calculation engine
and a better way to manage user interaction. And ultimately, I am looking
for a better way to perform regression testing.
It seems to me that we can make use of Subject/Observer pattern and
Model-View-Controller in the user interfaces to better manage validation. I
think I understand the concept, but in practice there are 10 ways to skin a
cat, and I get lost.
It seems that my calculation routines can make use of the decorator pattern.
Basically, I have a "LineItem" and should be able to create a single set of
code that takes into the slight differences in each of the LineItem types.
I get lost in factories, patterns, and the like.
We have tracing and log files embedded throughout the entire application and
libraries with varying levels of detail output. So now I can get miles of
information or none at all when a problem occurs. I know MS is recommending
test driven development and nUNIT is available for incorporation. First, I
haven't found too much information on creating tests in VS '05 Pro, and
certainly nothing that doesn't require Team server. And OMG, where do you
start with nUNIT? I want to do more than just test that a value is a date
or string.
I also think that I can make use of datasets and add appropriate code to
accomplish my needs. Certainly, creating dataviews become less of a hassle.
We used data objects because it seemed like a great idea. Well, more
specifically because we wanted to manage the SQL statements field by field
and to make use of SQLDataTypes so that we can have a Nullable object, since
Nullable(of ) doesn't support strings. And because strongly typed datasets
have an issue, we have not found a work around for, with null values when
bound.
We have some really brilliant code, and our bug history is impressively
short for a two year old application. However, we the developers know that
there are many opportunities for improvement. Before we propose/apply the
changes to the system, we have to better understand a better way to do the
work. We would like to incorporate these changes prior to exposing our
libraries via web services or creating web applications and extending the
database.
Any insight and comments are welcomed.
Thanks
