"Gav" <ga*@nospam.com wrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..
>
"Mr. Arnold" <MR. Ar****@Arnold.c omwrote in message
news:ed******** ******@TK2MSFTN GP02.phx.gbl...
>>
"Gav" <ga*@nospam.com wrote in message
news:%2******* *********@TK2MS FTNGP02.phx.gbl ...
>>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/is...taAccessLayer/
http://www.c-sharpcorner.com/UploadF...egant_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. :o)
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.
