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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>

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" <(E-Mail Removed)> a écrit dans le message de news:
%(E-Mail Removed)...

| 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

"Joanna Carter [TeamB]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Steve" <(E-Mail Removed)> a écrit dans le message de news:
> %(E-Mail Removed)...
>
> | 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
>
>


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

"Steve" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>
> "Joanna Carter [TeamB]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "Steve" <(E-Mail Removed)> a écrit dans le message de news:
>> %(E-Mail Removed)...
>>
>> | 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
>>
>>
>
>
> 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.
>
>

"Scott" <(E-Mail Removed)_YOU.com> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> >
> > "Joanna Carter [TeamB]" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >> "Steve" <(E-Mail Removed)> a écrit dans le message de news:
> >> %(E-Mail Removed)...
> >>
> >> | 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
> >>
> >>
> >
> >
> > 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.
> >
> >
>
>

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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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...
>
>

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 wrote:

>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...
>
>
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" <(E-Mail Removed)> a écrit dans le message de news:
e$(E-Mail Removed)...

| 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