Architecture guidelines

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

As a rule of thumb, is it good practice to abstract application
functionality from the form code behind in a c# winforms app? I have a
single form application, but I'm not sure where I should be doing my main
processing, if I should be working with the Form class instance or creating
an "engine" class and doing everything there? Are there any general
guidelines?

Hope that makes sense... ;)
 
Hello Steve,

it's a good practice to absctact app functionality from the everything, not
form :)
U need to extract interface from yout func code.
by the way, it the FW2.0 forms already separated from code

S> As a rule of thumb, is it good practice to abstract application
S> functionality from the form code behind in a c# winforms app? I have
S> a single form application, but I'm not sure where I should be doing
S> my main processing, if I should be working with the Form class
S> instance or creating an "engine" class and doing everything there?
S> Are there any general guidelines?
S>
S> Hope that makes sense... ;)
S>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
 
Michael Nemtsev said:
Hello Steve,

it's a good practice to absctact app functionality from the everything, not
form :)
U need to extract interface from yout func code.
by the way, it the FW2.0 forms already separated from code

S> As a rule of thumb, is it good practice to abstract application
S> functionality from the form code behind in a c# winforms app? I have
S> a single form application, but I'm not sure where I should be doing
S> my main processing, if I should be working with the Form class
S> instance or creating an "engine" class and doing everything there?
S> Are there any general guidelines?
S>
S> Hope that makes sense... ;)
S>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Click to expand...

Hi Michael, thank you for the reply
I'm not sure what you mean here "it the FW2.0 forms already separated from
code"
can you elaborate please?
 
"Steve" <[email protected]> a écrit dans le message de %[email protected]...

| As a rule of thumb, is it good practice to abstract application
| functionality from the form code behind in a c# winforms app? I have a
| single form application, but I'm not sure where I should be doing my main
| processing, if I should be working with the Form class instance or
creating
| an "engine" class and doing everything there? Are there any general
| guidelines?

You are heading in a very good direction here :-)

In theory, you should be able to build and test all your business classes
without any UI at all; using NUnit to buid your test framework. Then once
you have proven that your business classes are "bug-free", you can start to
think about how you want to display the properties of instances of those
classes.

Certainly, you should separate you app functionality from you UI; you might
also consider separating your app functionality from your database
connectivity; see some articles on OPFs (Object Persistence Frameworks) on
my website www.carterconsulting.org.uk they are targetting Delphi but the
principles are the same.

Joanna
 
Joanna Carter said:
"Steve" <[email protected]> a écrit dans le message de %[email protected]...

| As a rule of thumb, is it good practice to abstract application
| functionality from the form code behind in a c# winforms app? I have a
| single form application, but I'm not sure where I should be doing my main
| processing, if I should be working with the Form class instance or
creating
| an "engine" class and doing everything there? Are there any general
| guidelines?

You are heading in a very good direction here :-)

In theory, you should be able to build and test all your business classes
without any UI at all; using NUnit to buid your test framework. Then once
you have proven that your business classes are "bug-free", you can start to
think about how you want to display the properties of instances of those
classes.

Certainly, you should separate you app functionality from you UI; you might
also consider separating your app functionality from your database
connectivity; see some articles on OPFs (Object Persistence Frameworks) on
my website www.carterconsulting.org.uk they are targetting Delphi but the
principles are the same.

Joanna
Click to expand...


Thank you for the great response Joanna!

I'm glad you mention Data access, I was just designing that (on paper) and
will be using MS Access at first, then if all goes well moving to SqlServer,
so I figured that a data access class for each provider inheriting a common
interface would make the transition smoother in the future. I was also
considering the same approach for the UI, currently it's a desktop client,
but I would like to offer a web client later.

I will check out your links.
 
I used exclusively sql for a long time, so I always used SqlConnection,
etc... Then I discovered quite a while back the interfaces IDbConnection,
etc., which changed my entire outlook on db access. It does take some extra
work, sometimes (like when you actually need to instantiate a connection)
but works so much better and is database "independent" (almost).

Scott
 
Scott said:
I used exclusively sql for a long time, so I always used SqlConnection,
etc... Then I discovered quite a while back the interfaces IDbConnection,
etc., which changed my entire outlook on db access. It does take some extra
work, sometimes (like when you actually need to instantiate a connection)
but works so much better and is database "independent" (almost).

Scott
Click to expand...

Hi Scott,

From what I have read, the IDbConnection is an interface and I futher
understood that interfaces don't have implementation. So can you explain a
bit more how you would use this interface?

Thanks,
Steve
 
Steve said:
As a rule of thumb, is it good practice to abstract application
functionality from the form code behind in a c# winforms app? I have a
single form application, but I'm not sure where I should be doing my main
processing, if I should be working with the Form class instance or creating
an "engine" class and doing everything there? Are there any general
guidelines?

Hope that makes sense... ;)
Click to expand...

I'm realizing that I have a ton of questions about architecture design, lots
of ideas that I want to bounce around. Do any of you know of an appropriate
news group for such a discussion?
 
Steve said:
As a rule of thumb, is it good practice to abstract application
functionality from the form code behind in a c# winforms app? I have a
single form application, but I'm not sure where I should be doing my main
processing, if I should be working with the Form class instance or creating
an "engine" class and doing everything there? Are there any general
guidelines?

Hope that makes sense... ;)
Click to expand...
Yes it is a good practice. There are several caveats though. The
traditional c++ way has been to set up interfaces for everything. I
tend to use abstract classes/methods and virtual methods which gives you
everything interfaces give you plus ability to write code common to all
implementation just once. In addition, virtual classes allow you to
have fall back code (i.e. if the derived code doesn't implement it, the
app relies on the base implementation).

It is a good practice, no doubt. However, as you've probably found out,
it takes more setup time to do your app correctly. I've been in many
situations where the client needed the app yesterday and nothing else
mattered, so my principles had to stand aside for the purpose of expediency.

Regards
 
"Steve" <[email protected]> a écrit dans le message de [email protected]...

| From what I have read, the IDbConnection is an interface and I futher
| understood that interfaces don't have implementation. So can you explain
a
| bit more how you would use this interface?

PMFJI. we use interfaces a lot; they are essentially a contract that
guarantees that any class that implements that contract will provide the
declared properties and methods.

Declaring an interface allows you to state the services that your
data-access layer or UI will provide, but doesn't state *how* those services
will be provided. Thus you can write an Access OPF behind the interface and
also a SQL Server OPF behind the same interface.

Your application code always talks to the same interface, but you can change
the implementing class simply by deciding which OPF to instantiate.

Joanna
 
I use the interfaces like this (this code is just an example and isn't
tested)

I defined a class with static members "DbUtilties" which handles the actual
instantiation of a connection, since this cannot be done using the interface
alone. For simplicity, I defined an enum with the list of "supported"
databases, DbType.

IDbConnection conn = DbUtilities.GetConnection(DbType.SQL);
IDbCommand cmd = conn.CreateCommand();
....

From here it is pretty obvious. The only catch to this kind of thing is
that the syntax of the SQL stmt themselves varies slightly. MySql requires a
';' at the end of each statement. (since this doesn't affect microsoft sql,
i add the semicolon to all sql statements).

Scott
 
Scott said:
I use the interfaces like this (this code is just an example and isn't
tested)

I defined a class with static members "DbUtilties" which handles the actual
instantiation of a connection, since this cannot be done using the interface
alone. For simplicity, I defined an enum with the list of "supported"
databases, DbType.

IDbConnection conn = DbUtilities.GetConnection(DbType.SQL);
IDbCommand cmd = conn.CreateCommand();
...

From here it is pretty obvious. The only catch to this kind of thing is
that the syntax of the SQL stmt themselves varies slightly. MySql requires a
';' at the end of each statement. (since this doesn't affect microsoft sql,
i add the semicolon to all sql statements).

Scott
Click to expand...

Got it, Scott, thanks for the explanation.
 
Hello Steve,

I was talking about partial classes, this idea is prolong to the Avalon.

The gist is in dividing form designing and codding.
All forms for desiners and code for developers.


S> Hi Michael, thank you for the reply
S> I'm not sure what you mean here "it the FW2.0 forms already separated
S> from
S> code"
S> can you elaborate please?
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
Back
Top