The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Which Design should I use???

Hi,

I'am developing a application which contain a lot of forms. Every Form has a datagridView, DataSet and operations to manage these objects...
I want to simplify the code of my forms which is complicated. I'm thinking to use the Strategy pattern or the builder to put out the repeated operations.
In every form, i connect to the database, fill the dataset, display the datagridView etc... theses operations are different in each Form, but the principle still the same, may i use the strategy pattern???

may somebody help me????


thank you and sorry for my bad english :-(
Esprit_tolerant Send private email
Friday, January 19, 2007
 
 
You could make a configurable framework and then only add and remove items in the configuration.

I did that, all in VBScript (as a business user, I'm not even allowed to think about Visual Studio or what). Everything neatly done with classes. Took me 2 weeks in idle time waiting for dwh queries to complete.

What is more, I don't need a web server (and I don't have one) - everything is client-based code, which in my case (hello IE) is vbscript in a html file with linked vbs libraries.

Example of a config file entry. This process asks for a SQL query runs it against database and outputs results in a excel sheet.

<process name="SQL query to excel" id="sqlQueryToExcel">
 <parameters>
  <parameter id="TeradataUser" type="system"/>
  <parameter id="TeradataPassword" type="system"/>
  <parameter id="InputtedQuery" type="askUser"/>
 </parameters>
 <phases>
  <phase type="Connect" name="Connecting to Teradata" id="TeradataConnect">
  <data id="ConnectionString">DSN=teradata;UID=@@TeradataUser@@;PWD=@@TeradataPassword@@</data>
  </phase>
  <phase type="SQLQuery" name="SQL Query" id="TeradataQuery">
  <data id="ConnectPhaseId">TeradataConnect</data>
  <data id="Query">@@InputtedQuery@@</data>
  </phase>
  <phase type="SQLQueryExcelReport" name="Creating Excel report" id="SQLQueryExcelReport">
  <data id="QueryPhaseId">TeradataQuery</data>
  </phase>
  <phase type="Disconnect" name="Disconnecting from Teradata" id="TeradataDisconnect">
  <data id="ConnectPhaseId">TeradataConnect</data>
  </phase>
 </phases>
</process>
Wojtek Send private email
Friday, January 19, 2007
 
 
Yes, the Strategy pattern would be be a good approach to use.
Mike S Send private email
Friday, January 19, 2007
 
 
This involves a mindset/architecture as opposed to a specific "pattern". It may involve using multiple patterns in your implementation.

You need to step back and have the mindset that you intend to make it easy for non-experienced programmers to write good code. To do this you will want to reduce the work involved in creating a simple form.

Here is an example. If you hire a new programmer who knows nothing about the system and you need to tell them to "Don't forget to close the database connection. Oh, and make sure that you validate that all dates values entered can actually be converted to a date." then you've failed. These things should be handled consistently in your system in a way that keeps the programmer from having to worry about them.

Here are a few details about how I implement basic CRUD apps to get you thinking along the right lines.

1) There are only 5 places in my entire solution where the database is opened and closed. These correspond to the actions of update, insert, delete, read a single record, read a list of records. All database logic is encapsulated in the data layer. There is no need for a programmer to ever program update/delete/insert statements. They are automatically generated based on metadata supplied by the O/R data object itself. Reads are handled by the user creating a database command and passing it into the data layer by calling either ReadSingle or ReadList. This keeps people from having to worry about opening and closing databases. If you require programmers to remember to always close a connection when they're done with it then they will eventually mess up and you will leak connections. This also allows you to easily transition data access to something like a web service if you want to. The developer is completely insulated by the idea that a database is backing their data.

2) A typical CRUD screen should perform all of the basic plumbing under the covers. Programmers should never manually be coding logic to implement things like save functions. Requiring a programmer to remember to attach an event to the save button's click event is ridiculous. The act of saving something is always the same. The same can be said of most of the other actions in a screen. I've reduced the requirements of programmers down into three main steps: A) Override an OnRetrieve method which is called when a search is performed. In this method they call a function that returns either a single row or multiple rows from the database (or none). B) Override an OnValidate method to perform special validation based on business logic. This does not included making sure that a text value entered can be changed into a date (see section #3 below). This method is only used for special validations not related to data types. For example, a certain date field can't be greater than 30 days from today. C) Override an OnBinding method to perfrom the actual binding from an O/R data object and the input controls on the screen.

3) If you are expecting your programmers to perform input validation on every single control on the form then you are in trouble. I have type-specific input controls that are used that provide the basic validation needed. For example, a currency field would be edited only through a CurrencyInputControl. The developer simply drags one onto the form and is guaranteed that the control won't let the user enter a value into it that can't be converted into a monetary value. The same can be said for dates, email addresses, even phone numbers. This centralizes all of this basic validation and relieves the developer from having to worry about it. If your current system involves a developer dragging a standard TextBox onto a form and having to remember to perform validation on it in some sort of TextChanged event then they are going to mess it up. You end up with validation code all over the place and each programmer will either forget or do it differently.

So to summarize, I'd like to give an example of what a programmer would need to do to add a new phone number field to a form. They would open the form, drag a PhoneInputControl onto it, set basic properties like the title text and whether or not it is a required field; go to the OnBinding method and add a single line of code to bind the equivalent O/R data column to the newly added control; add any special validation needed in OnValidate (which usually is nothing for things like phone numbers). And save. That's it. It couldn't be any easier. A monkey could do it and the odds of them making a mistake are close to nil.

So when I talk out here about building architectures instead of using things like code generators I'm talking about a "mindset" that is aimed at reducing repeated code AND repeated programming tasks. Centralizing code allows widesweeping changes to be made in a single place. Maintenance costs go way down and you end the cycle of programmers breaking more things every time they add new functionality.

Thanks for listening.  ;)
Turtle Rustler
Friday, January 19, 2007
 
 
I second the Turtle Rustler in that what you are looking for is more of a framework than a particular pattern. The framework would be made up several patterns one of them being some sort of strategy based of an object type etc. Recently I implemented a similar type of framework for a customer where I used a base form that handled the basics (coving 90% of the typical CRUD type requirements) where everything was overridable etc. From a strategy point of view the form would load up its relevant business and data objects calling services such as add, update, delete or search. It worked quite well and with the constant changes that flowed through the system it removed a massive amount of changes etc. The framework itself took a bit of work but is very re-usable. One of the challenges I kept in the back of my mind at all times was "some poor maintenance programmer will need to change/add to this one day..."
PK Software Send private email
Sunday, January 21, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz