Database Application Example

[Gav]

I'm writing a windows application (using C# VS 2005 Pro) to access a MS SQL
database and although it is working fine (up to now) I'm not sure I'm going
about it in the best way. Can anybody point me to any good examples online
that i can look at, found loads of web applications but struggling to find a
good windows application example.

thanks

Gav

 

[Mr. Arnold]

I'm writing a windows application (using C# VS 2005 Pro) to access a MS
SQL database and although it is working fine (up to now) I'm not sure I'm
going about it in the best way. Can anybody point me to any good examples
online that i can look at, found loads of web applications but struggling
to find a good windows application example.

If you abstract the form from the data access, then it shouldn't matter what
the form Web or Windows is being used. The form should be decoupled from
data access with SQL Server.

http://msdn.microsoft.com/msdnmag/issues/03/04/DataAccessLayer/
http://www.c-sharpcorner.com/UploadFile/rmcochran/elegant_dal05212006130957PM/elegant_dal.aspx

I am sure you can find other examples using Google about the DAL.

You might also want to look into the UI/Business layer/Data Access layer
concepts

The UI uses a business layer object to access the data access layer object.
The UI never makes a direct call to the DAL or no direct calls to the
database. It goes through the business object.

You can do an even more abstraction of the UI from all other layers by using
MVP concepts. No reference to the BL at all from the UP, the UI goes through
the presentation layer to the BL and BL to the DAL, using interfaces. The UI
should be unaware of the BL. You return all properties of the BL object on
the MVP interface. If you need to bind data from SQL server to a control,
then you use a DataTable as the return type through the MVP interface, as an
example from the BL/DAL objects. No BL object and it's properties should
ever be addressed at UI.

UI/MVP/BL/DAL.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

You should also understand an object's Public accessor properties of Get/Set
in C#.

 

[sloan]

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

Download the source code.

Basically, replace the "Program.cs" with a new Folder, like
"Presentation.Winforms" (aka, create a new folder, and put your form files
in there)
and you'll have a NLayered application.

In my demo, the console application is the "presentation layer", as crappy
as it is.

The code-behind of your buttons (on any of your forms) shouldn't know
anything about database connection strings, sqlcommand, sql connection
objects.
They should know about the BusinessLayer.

You might want to get the 1.1 version of the project above:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

because there I think I seperate out the layers into different assemblies.
The second link also has a VERY GOOD MS link at the bottom. Go find that
article and read it, reread it a few times.

 

[Gav]

If you abstract the form from the data access, then it shouldn't matter
what the form Web or Windows is being used. The form should be decoupled
from data access with SQL Server.

http://msdn.microsoft.com/msdnmag/issues/03/04/DataAccessLayer/
http://www.c-sharpcorner.com/UploadFile/rmcochran/elegant_dal05212006130957PM/elegant_dal.aspx

I am sure you can find other examples using Google about the DAL.

You might also want to look into the UI/Business layer/Data Access layer
concepts

The UI uses a business layer object to access the data access layer
object. The UI never makes a direct call to the DAL or no direct calls to
the database. It goes through the business object.

You can do an even more abstraction of the UI from all other layers by
using MVP concepts. No reference to the BL at all from the UP, the UI goes
through the presentation layer to the BL and BL to the DAL, using
interfaces. The UI should be unaware of the BL. You return all properties
of the BL object on the MVP interface. If you need to bind data from SQL
server to a control, then you use a DataTable as the return type through
the MVP interface, as an example from the BL/DAL objects. No BL object and
it's properties should ever be addressed at UI.

UI/MVP/BL/DAL.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

You should also understand an object's Public accessor properties of
Get/Set
in C#.

Thanks for your detailed reply to my question. I've watched the podcasts
they are great. I get the point of splitting things down to make changes and
testing easier but I'm a little confused over persistence.

For example in my application (winform) after opening the main window a user
can choose to login to the application, at which point a popup opens asking
the user to login. Then I populate my User class with various authorisations
etc and use it for the remainder of the time the user is logged in. I'm not
sure how I would do this using the MVP model, where would my User class be
and how would it be referenced? Looking at the examples so far the (if i'm
understanding them correctly) each windows Form has reference to a
particular view class and the view class has reference to the business logic
classes. So on changing forms the instance of the User class would no be
visable.

This is all new to me so I may be missing something obvious, or just be
completely wrong in my understanding so far. )

Gav

 

[Mr. Arnold]

Thanks for your detailed reply to my question. I've watched the podcasts
they are great. I get the point of splitting things down to make changes
and testing easier but I'm a little confused over persistence.

For example in my application (winform) after opening the main window a
user can choose to login to the application, at which point a popup opens
asking the user to login. Then I populate my User class with various
authorisations etc and use it for the remainder of the time the user is
logged in. I'm not sure how I would do this using the MVP model, where
would my User class be and how would it be referenced? Looking at the
examples so far the (if i'm understanding them correctly) each windows
Form has reference to a particular view class and the view class has
reference to the business logic classes. So on changing forms the instance
of the User class would no be visable.

This is all new to me so I may be missing something obvious, or just be
completely wrong in my understanding so far. )

Your User class is a Business object or object model that's actually at the
Business Layer. The UI should be unaware of the Business object. Your
solution should be loosely coupled in that regard. That means that there
should not be a reference to the Business layer if at all possible from the
UI layer. This is not a hard and study rule, but it is one that you should
follow as much as possible.

So with that said, you extract everything from the User class that is needed
and you bring like type fields back through the MVP Interface, string
UserName to Public Interface string.Username { set; }. You bring everything
back field by field.

Then at the UI at the UserName interface, you're going to use the Set value
and set (private string username) from the value of the returned Interface
field, as an example. You bring it all back through the MVP Interface field
by field.

Again, the UI should be unaware of a model object/Business object.

That Service Layer example is using a Business Object Reference and a <List>
to bind it to a control at the UI with a reference to the BL at the UI. But
you don't need that Service Layer, if you don't want to use it.

You can use a Dataset and DataTable and bring that DataTable back from the
DAL through the BL and through the MVP Interface as a DataTable back to the
UI and bind the DataTable to the control at the UI, with out the Service
layer. In this way, the UI still knows nothing about the BL or a model
object.

 

[Mr. Arnold]

This demo about Login may help you too.

http://www.codeproject.com/useritems/mvpBasicDemo.asp