>> 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
[quoted text clipped - 56 lines]
> 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)
Gav
Mr. Arnold - 29 Oct 2007 22:57 GMT
>>> 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
[quoted text clipped - 74 lines]
> 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.
Mr. Arnold - 30 Oct 2007 00:25 GMT
This demo about Login may help you too.
http://www.codeproject.com/useritems/mvpBasicDemo.asp