structure of a program

  • Thread starter Thread starter gordon
  • Start date Start date
G

gordon

Hi

I am still fairly new to C#.net and I sometimes make basic program design
mistakes - particularyly in the context of paying attention to OOP
principles.

At the moment I am working on an application that uses a MS Access database
and runs some queries that return output to a datagrid. I would like to
consider the best structure of the program so that I can start to get into
good habits for other similar projects.

I have a few questions that I would appreciate some advice on.

First is about structure - is there a standard way of writing OOP code -
that is understandable by novices?

Second is about my particular application. At the moment I have a file
called First.cs that contains the class called 'First :Form' which in turn
contains the the main method and the click events that are fired by a user.
I also have a method within this class that is called GetData that actually
contains the OleDB commands and is passed a parameter the is used in a
'Select...' string. I was trying to move the GetData method into a class of
its own - but I keep getting errors about some of the components within the
method that generate out of context type errors. For example, I have a
dataGridView called dgMainView that will display the result of the query,
but this is not easy to reset in the new class - as are some other controls
that are on the form. Is there a simple way around this - or do I have to
set all of my form controls to public rather than private? Alternatively,
am I going about this the wrong way in general>

Thanks

Any help appreicated.

Doug
 
Is there a simple way around this - or do I have to
set all of my form controls to public rather than private?
Click to expand...

I wouldn't recommend making them public; the underyling problem here is
that you have a melange of UI and database code. One of the pillars of
OO is encapsulation; each class does one thing (or a number of related
things), with some plumbing code to link it all together; the
implementation details of that "thing" are private to the class.

By this, I mean (specifically) that your database code should know
nothing about the UI; just the database. Likewise, the UI layer should
know nothing about the internals of talking to the database - just that
there is a data-access class that it can use. The GetData() could (for
instance) return a DataSet of the data (if you like such objects), or
array(s)/collection(s) representing the data. The code at the UI layer
would typically invoke the data-access layer [DAL], and then render the
UI accordingly (which could mean assigning data to bindings, or
manually building the display).

The huge advantage of this type of approach is that the same DAL can
support multiple concurrent and disparate UIs (e.g. a web UI and a
winform UI, or just two different forms in the same app), and the UI
can be changed independently of the DAL (adding columns etc).

Hope this helps,

Marc
 
Thanks Marc,

I think I am aiming at what you describe. However it is often quite
difficult for a novice to actually achieve this.

For example, I have structured my code in a way that creates an object of a
DataGet class but I constantly get errors about the DataSet - DS - not being
available in the current context. Do you have any sample code that I could
build on or do you know any examples of where this has been done well?

Thanks again for your kind advice.


Doug

Marc Gravell said:
Is there a simple way around this - or do I have to
set all of my form controls to public rather than private?
Click to expand...

I wouldn't recommend making them public; the underyling problem here is
that you have a melange of UI and database code. One of the pillars of
OO is encapsulation; each class does one thing (or a number of related
things), with some plumbing code to link it all together; the
implementation details of that "thing" are private to the class.

By this, I mean (specifically) that your database code should know
nothing about the UI; just the database. Likewise, the UI layer should
know nothing about the internals of talking to the database - just that
there is a data-access class that it can use. The GetData() could (for
instance) return a DataSet of the data (if you like such objects), or
array(s)/collection(s) representing the data. The code at the UI layer
would typically invoke the data-access layer [DAL], and then render the
UI accordingly (which could mean assigning data to bindings, or
manually building the display).

The huge advantage of this type of approach is that the same DAL can
support multiple concurrent and disparate UIs (e.g. a web UI and a
winform UI, or just two different forms in the same app), and the UI
can be changed independently of the DAL (adding columns etc).

Hope this helps,

Marc
Click to expand...
 
Well, if you can post the lines that it doesn't like, and the *exact*
error message, we can probably sort it out. It is probably just either
namespace issue, or mixing up static/instance usage; if you are in
VS2005, does the class name come up in a different color? Try
right-clicking on it and Resolve -> using {blah} to add a "using"
statement to your class; also, if you post anything, the bare-bones
skeleton to your DataAccess would be helpful. Example (for you to post)
is below. Note that it is largely a matter of style and
project-specific needs whether (for instance) DAL methods are static or
instance oriented - this is not central to what we are looking at
here...

// **** form button-click method:
private void SomeButton_Click(object sender, EventArgs args) {
// <snip init code>

// get data
DataSet ds = NameOfDALClass.GetData();

// <snip UI code>
}

// **** DAL code
namespace SomeNamespace.SomeInnerNamespace {
public class NameOfDALClass {
public static DataSet GetData() {
// <snip DAL code>
}
// <snip other methods>
}
}

Thanks Marc,

I think I am aiming at what you describe. However it is often quite
difficult for a novice to actually achieve this.

For example, I have structured my code in a way that creates an object of a
DataGet class but I constantly get errors about the DataSet - DS - not being
available in the current context. Do you have any sample code that I could
build on or do you know any examples of where this has been done well?

Thanks again for your kind advice.


Doug

Marc Gravell said:
Is there a simple way around this - or do I have to
set all of my form controls to public rather than private?
Click to expand...

I wouldn't recommend making them public; the underyling problem here is
that you have a melange of UI and database code. One of the pillars of
OO is encapsulation; each class does one thing (or a number of related
things), with some plumbing code to link it all together; the
implementation details of that "thing" are private to the class.

By this, I mean (specifically) that your database code should know
nothing about the UI; just the database. Likewise, the UI layer should
know nothing about the internals of talking to the database - just that
there is a data-access class that it can use. The GetData() could (for
instance) return a DataSet of the data (if you like such objects), or
array(s)/collection(s) representing the data. The code at the UI layer
would typically invoke the data-access layer [DAL], and then render the
UI accordingly (which could mean assigning data to bindings, or
manually building the display).

The huge advantage of this type of approach is that the same DAL can
support multiple concurrent and disparate UIs (e.g. a web UI and a
winform UI, or just two different forms in the same app), and the UI
can be changed independently of the DAL (adding columns etc).

Hope this helps,

Marc
Click to expand...
Click to expand...
 
gordon said:
Hi

I am still fairly new to C#.net and I sometimes make basic program design
mistakes - particularyly in the context of paying attention to OOP
principles.

At the moment I am working on an application that uses a MS Access
database and runs some queries that return output to a datagrid. I would
like to consider the best structure of the program so that I can start to
get into good habits for other similar projects.

I have a few questions that I would appreciate some advice on.

First is about structure - is there a standard way of writing OOP code -
that is understandable by novices?

Second is about my particular application. At the moment I have a file
called First.cs that contains the class called 'First :Form' which in turn
contains the the main method and the click events that are fired by a
user. I also have a method within this class that is called GetData that
actually contains the OleDB commands and is passed a parameter the is used
in a 'Select...' string. I was trying to move the GetData method into a
class of its own - but I keep getting errors about some of the components
within the method that generate out of context type errors. For example, I
have a dataGridView called dgMainView that will display the result of the
query, but this is not easy to reset in the new class - as are some other
controls that are on the form. Is there a simple way around this - or do
I have to set all of my form controls to public rather than private?
Alternatively, am I going about this the wrong way in general>
Click to expand...

You should keep the controls private. The methods that deal with the
controls are in the code behind. Make the UI code as thin as possible. If
you are wanting the controls to respond to actions in another classes or
other layers like a data or business layer then the form should subscribe to
an event that will be raised by the data / business layer.

For example the user enters the query test and clicks a button. The button
click event does something like MyQueryObect.RunQuery(this.myTextBox.txt).
Because you have already hooked up to the QueryCompleted event then the form
does nothing else until this event is fired and then the QueryCompleted
event passes the result of the query as an event argument and your form then
displays the results.

SP
 
Back
Top