Architecture guidelines

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... ;)

re: Architecture guidelines

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

re: Architecture guidelines

"Michael Nemtsev" <nemtsev@msn.com> wrote in message
news:43daf23227123e8c791c71f66d804@msnews.microsof t.com...[color=blue]
> Hello Steve,
>
> it's a good practice to absctact app functionality from the everything,[/color]
not[color=blue]
> 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[/color]
not[color=blue]
> cease to be insipid." (c) Friedrich Nietzsche
>
>[/color]

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?

re: Architecture guidelines

"Steve" <sss@sss.com> a écrit dans le message de news:
%23vwBox4wFHA.3772@TK2MSFTNGP11.phx.gbl...

| 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 [TeamB]
Consultant Software Engineer

re: Architecture guidelines

"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message
news:O0pUDE5wFHA.908@tk2msftngp13.phx.gbl...[color=blue]
> "Steve" <sss@sss.com> a écrit dans le message de news:
> %23vwBox4wFHA.3772@TK2MSFTNGP11.phx.gbl...
>
> | 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[/color]
main[color=blue]
> | 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[/color]
to[color=blue]
> 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[/color]
might[color=blue]
> 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 [TeamB]
> Consultant Software Engineer
>
>[/color]


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.

re: Architecture guidelines

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

"Steve" <sss@sss.com> wrote in message
news:%230jLAH5wFHA.720@TK2MSFTNGP15.phx.gbl...[color=blue]
>
> "Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message
> news:O0pUDE5wFHA.908@tk2msftngp13.phx.gbl...[color=green]
>> "Steve" <sss@sss.com> a écrit dans le message de news:
>> %23vwBox4wFHA.3772@TK2MSFTNGP11.phx.gbl...
>>
>> | 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[/color]
> main[color=green]
>> | 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[/color]
> to[color=green]
>> 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[/color]
> might[color=green]
>> 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 [TeamB]
>> Consultant Software Engineer
>>
>>[/color]
>
>
> 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.
>
>[/color]

re: Architecture guidelines

"Scott" <sdcoonce@gmail.HEY_YOU.com> wrote in message
news:OKO8QR5wFHA.3720@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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[/color]
extra[color=blue]
> work, sometimes (like when you actually need to instantiate a connection)
> but works so much better and is database "independent" (almost).
>
> Scott
>
> "Steve" <sss@sss.com> wrote in message
> news:%230jLAH5wFHA.720@TK2MSFTNGP15.phx.gbl...[color=green]
> >
> > "Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message
> > news:O0pUDE5wFHA.908@tk2msftngp13.phx.gbl...[color=darkred]
> >> "Steve" <sss@sss.com> a écrit dans le message de news:
> >> %23vwBox4wFHA.3772@TK2MSFTNGP11.phx.gbl...
> >>
> >> | 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[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >> | single form application, but I'm not sure where I should be doing my[/color]
> > main[color=darkred]
> >> | 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[/color][/color][/color]
classes[color=blue][color=green][color=darkred]
> >> without any UI at all; using NUnit to buid your test framework. Then[/color][/color][/color]
once[color=blue][color=green][color=darkred]
> >> you have proven that your business classes are "bug-free", you can[/color][/color][/color]
start[color=blue][color=green]
> > to[color=darkred]
> >> think about how you want to display the properties of instances of[/color][/color][/color]
those[color=blue][color=green][color=darkred]
> >> classes.
> >>
> >> Certainly, you should separate you app functionality from you UI; you[/color]
> > might[color=darkred]
> >> 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[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> principles are the same.
> >>
> >> Joanna
> >>
> >> --
> >> Joanna Carter [TeamB]
> >> Consultant Software Engineer
> >>
> >>[/color]
> >
> >
> > Thank you for the great response Joanna!
> >
> > I'm glad you mention Data access, I was just designing that (on paper)[/color][/color]
and[color=blue][color=green]
> > 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[/color][/color]
client,[color=blue][color=green]
> > but I would like to offer a web client later.
> >
> > I will check out your links.
> >
> >[/color]
>
>[/color]

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

re: Architecture guidelines

"Steve" <sss@sss.com> wrote in message
news:%23vwBox4wFHA.3772@TK2MSFTNGP11.phx.gbl...[color=blue]
> 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[/color]
creating[color=blue]
> an "engine" class and doing everything there? Are there any general
> guidelines?
>
> Hope that makes sense... ;)
>
>[/color]

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?

re: Architecture guidelines

Steve wrote:
[color=blue]
>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... ;)
>
>[/color]
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

re: Architecture guidelines

"Steve" <sss@sss.com> a écrit dans le message de news:
e$FkqV5wFHA.1252@TK2MSFTNGP09.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer

re: Architecture guidelines

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

re: Architecture guidelines

"Scott" <sdcoonce@gmail.HEY_YOU.com> wrote in message
news:O1BzMb$wFHA.720@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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[/color]
actual[color=blue]
> instantiation of a connection, since this cannot be done using the[/color]
interface[color=blue]
> 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[/color]
a[color=blue]
> ';' at the end of each statement. (since this doesn't affect microsoft[/color]
sql,[color=blue]
> i add the semicolon to all sql statements).
>
> Scott
>
>[/color]

Got it, Scott, thanks for the explanation.