Where to Put DAL and Business Objects in WinForms App?

[Smithers]

In Windows Forms MDI applications...

I'm wondering if it is standard practice to create DAL and business objects
as static classes. The only alternative (please enlighten me if I'm wrong
about this) is to instantiate the DAL and business objects in a Form class -
most likely the MDI parent - and then expose the business objects as public
members.

What is standard practice here? [assuming we're not using DCOM or Remoting
or Web services or any other such remote procedure calls].

Thanks!

[Jon Skeet [C# MVP]]

Smithers <[e-mail]> wrote:

I'm wondering if it is standard practice to create DAL and business objects
as static classes. The only alternative (please enlighten me if I'm wrong
about this) is to instantiate the DAL and business objects in a Form class -
most likely the MDI parent - and then expose the business objects as public
members.

What is standard practice here? [assuming we're not using DCOM or Remoting
or Web services or any other such remote procedure calls].

The disadvantage with using static classes is that you're then bound to
that implementation.

I prefer to use interfaces between layers, and use dependency injection
to give each layer the stateless objects from the layer below to use.
(If new objects need creating, they tend to be within layers, or could
be created with a factory pattern.)

Spring is a great way of doing dependency injection:
http://www.springframework.net

(I haven't used the .NET version, just the Java one, but it's great.
Really handy for unit testing, too.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[john conwell]

Total overkill in my humble opinion.
I think there are a good middle ground between simple static classes, and
creating a totally abstract, interface driven framework, dependant on a third
party library.

Don’t worry about stateless objects. If there are no remote objects (COM+,
WS, Remoting) there is absolutely no need to go create your classes so
they'll be stateless. just create normal instance based classes for your BL.
I tend to use factories to return objects from my DAL, but that’s just a
preference. You can go with normal instance based classes there as well.

One of my favorite quotes (from one of the TDD / Agile gurus) that I always
try to keep in mind when designing a new framework for an application goes
something like this. "Don't design something overly complex and unnecessary
just for the simple intellectual stimulation of it. Design for what you need
right now." You should keep in mind future extensibility, but don't just
through hoops to create the ultimate flexible framework. You'll end up with
way more than you ever need.
"Jon Skeet [C# MVP]" wrote:

Smithers <[e-mail]> wrote:

I'm wondering if it is standard practice to create DAL and business objects
as static classes. The only alternative (please enlighten me if I'm wrong
about this) is to instantiate the DAL and business objects in a Form class -
most likely the MDI parent - and then expose the business objects as public
members.

What is standard practice here? [assuming we're not using DCOM or Remoting
or Web services or any other such remote procedure calls].

The disadvantage with using static classes is that you're then bound to
that implementation.

I prefer to use interfaces between layers, and use dependency injection
to give each layer the stateless objects from the layer below to use.
(If new objects need creating, they tend to be within layers, or could
be created with a factory pattern.)

Spring is a great way of doing dependency injection:
http://www.springframework.net

(I haven't used the .NET version, just the Java one, but it's great.
Really handy for unit testing, too.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

john conwell <jo*********@di scussions.micro soft.com> wrote:

Total overkill in my humble opinion.
It actually makes life a lot simpler, to be honest.
I think there are a good middle ground between simple static classes, and
creating a totally abstract, interface driven framework, dependant on a third
party library.
What's wrong with depending on a third-party library?
Don?t worry about stateless objects. If there are no remote objects (COM+,
WS, Remoting) there is absolutely no need to go create your classes so
they'll be stateless. just create normal instance based classes for your BL.
I tend to use factories to return objects from my DAL, but that?s just a
preference. You can go with normal instance based classes there as well.
And how do you unit test the classes which create DAL objects then? By
hard-coding your classes to create instances of each other, you're
adding dependencies which don't need to be there. Note that none of the
business classes themselves depend on Spring in the kind of setup I'm
talking about - Spring is just there to wire things up.
One of my favorite quotes (from one of the TDD / Agile gurus) that I always
try to keep in mind when designing a new framework for an application goes
something like this. "Don't design something overly complex and unnecessary
just for the simple intellectual stimulation of it. Design for what you need
right now." You should keep in mind future extensibility, but don't just
through hoops to create the ultimate flexible framework. You'll end up with
way more than you ever need.

Nope, I end up with exactly what I need - an application which is
really easy to unit test and configure. When all the collaborators are
set through interfaces, it means you can mock them very easily and
genuinely test just a unit instead of a whole bunch of classes at a
time.

The Spring framework developers are big Agile/TDD fans too, btw...
that's why it's a framework which scales down as well as up.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too