Re: decouple gui from bo


"MP" <NoSpam@xxxxxxxxxx> wrote in message
news:Od5zf2gzHHA.5408@xxxxxxxxxxxxxxxxxxxxxxx

"Steve Gerrard" <mynamehere@xxxxxxxxxxx> wrote in message
news:I82dnWTjG-L88jjbnZ2dnUVZ_j-dnZ2d@xxxxxxxxxxxxxx

Like I said originally(and the thread title) this was only in the context of
trying to understand the recommendation I saw somewhere about separating the
gui layer from the business objects layer.
So far neither you nor Ralph has specifically said that was or was not a
reasonable design goal.

My first response in this thread was
"In my view, forms can and should know about the various classes they use, just
not the other way around."

I suspect you are thinking of a proposal you made to specify a ListBox as a
parameter to a method in your collection class. That would mean the class
knowing about the form, and avoiding that is I believe what was recommended.

Presentation knows about the business layer. Business knows about the data
layer. Data layer just knows the data.


The key is to design the class so that it can be used in more than one place,
by more than one kind of host, for more than one purpose. Make it generic
enough to be useful for a variety of tasks.

again, that's what I *thought* I was doing.
My intention in this design was:
abstract concept of client into class cClient
group clients into collection class cClients
provide services to other parts of the app as req'd...in this case list of
client names

No problem. A list of names, as opposed to a list of cClient objects that have a
Name property, just seems unecessary. Collections are standard ways of passing
stuff around; a collection of objects of some particular class is fine to use
directly.


Ok, now that brings up another "principle" I've seen much debate on.
I thought the concensus was global objects were a no-no.

Well, yes and no. It depends on the structure of the particular app. Unless you
are going to create the client list from scratch every time it is needed, or
keep a separate one in every form, what else would you do? There has to be an
anchor somewhere, if you are going to have an app with multiple forms using the
same data. For some apps, that can be a database. For others, it makes sense to
have a central place to store the working data.

"a public function in a module " that is basically global to the project
right?
but you're saying that's ok?

Yes, if you don't over do it. It can help to name the module GlobalData.bas. You
could make it a public property to give it a little shelter, something like

Private mClients As cClients
Public Property Get Clients() As cClients
' perform checks here if desired
Set Clients = mClients
End Property

Then form load listbox becomes
Private Sub LoadClientNames()
For Each oClient In GlobalData.Clients

another question I have related to putting the object in a bas module (besides
people generally saying stay away from globals) is that If I define the class
in a module I can't use events (if I were to want to)
in this specific small example I'm not, but just in principle, if other
classes were using the goClients object they too would be deprived of events

any thoughts?



If Form1 needs to receive events from the collection, you can do
' in general declaration
Private WithEvents TheClients As cClients
' in Form_Load
Set TheClients = GlobalData.Clients
' imaginary event handler
Private Sub TheClients_BigEvent()
' act accordingly
End Sub


Other than the exact name of the property, this is what I have.
oClient.Name
(in this app(and any app I make for our inhouse use) client happens to be a
company, so in this instance the first,last,middle don't come into play)


Maybe not, but the point is that a form does not need to know that. The property
might just pass back a stored string, or it might make a call to Timbuktu first.
Form doesn't care. Just wants the Name.

By the way, most frown on using Name for a property, since it is already used a
lot in VB...





.

Relevant Pages

  • Re: Data Limitations
    ... My database layer is getting a major upgrade due to .Net capabilities. ... App for HIPAA reporting and everyone needed the same data shown a different ... also needed to resuse this logic for a client side desktop app. ... making another trip to the db wasn't an option. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: "Porting" a desktop app to a web application - best practices ?
    ... What u need to understand that the web client differs from windows client in tems of stateness - u need concentrate on States, Cookies, ViewState, Sessions to understand how to implement your client ... Another area where put attentions is controls - if you have comples UI u need to understand which libs and controls you are going to use ... Db related logic is in the DB layer (mostly implemented by stored ... (> "converting" the application form a desktop app to a web app. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How to test wireless problem?
    ... the client to just disappear when it goes into hibernate. ... It tries to continue the previous connection at all ... layers from the applications layer, ... disconnect between layers at both ends. ...
    (alt.internet.wireless)
  • Re: OODesign - OPF, design pattern
    ... I wanted to put across that an app layer is ... if you hadn't used the framework in the first place. ... the plugins to be managed or unmanaged. ...
    (borland.public.delphi.non-technical)
  • Re: OODesign - OPF, design pattern
    ... I developed a Pocket PC app last year using the compact framework. ... Maybe my design is just very simple then, ... and its in the application layer not the business ...
    (borland.public.delphi.non-technical)