Model / GUI separation 1

[1DMF]

Hi,

Since studying I have been taught that you should always separate the model into a class and the GUI (Form) should not do any of the 'work' to perform tasks other than basic click events which call methods in the underlying model and the 'updateView' method to keep the GUI and model in sync with each other.

should I be applying the same logic to MS Access?

How does that work when you have bound data to the form's controls?

I have many routines / processes which run from the onclick event of a button on the form, is this really bad?

Or is the way you develop in MS Access different to standard VB applications?

As MS Access is not true OO and has many limitations such as no contructor, is it not possible to code applications using the same principles I am being taught on my VB course?

Your advice is appreciated.

Regards,
1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[MichaelRed]

Classes teach A methodology. Life usually teaches alternatives to the classroom. If we all strictly followed the textbook approaches, change (e.g. progress) would not exist. Neither the textbook or life offer complete soloutions to any but the most simplistic issues.

Shoud be enough to at least get you to THINK!!!!!!!!!




MichaelRed

 

[TheAceMan1]

How are ya 1DMF . . .

[blue]Since studying I have been taught that you should always separate the model into a class and the GUI (Form) should not do any of the 'work' to perform tasks other than basic click events which call methods in the underlying model ...[/blue]

Your restricting yourself quite a little too much!

Consider: if you can't do it with the access interface ... then you have to do it in code! There's no other way out! You tell me ... what else can you do! ...

[blue]So ... its not what you know ... its how you apply it![/blue] Consider what you know as a reservoir of resources at your disposal. You simply need to add to these resources how access does things ... aka [blue]Object Orenitation[/blue] ... which is the key to database design.

When I design a DB ... most of what I've learned never comes into play. Dealing with access does! I need to decide on table content and relationships in making my tables. Then I move to the forms. From what you know ... you allow table design to follow as best it can. Taking into account all the rules of what you know. [blue]There's always a trade-off in what you know verses what needs to be done[/blue]. In the end ... if you go back ... you'll find there isn't much that follows what you think you know! ... Thats the way it is! ... [blue]Thats DB design![/blue] ...

I promise ... you'll make more money with something out of the norm ... that something within!

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

Be sure to see thread181-473997 [blue]Worthy Reading![/blue]
Also faq181-2886 [blue]Worthy Reading![/blue]

 

[1DMF]

hmm, so you both think that the course is teaching a strict a methodology not practicle in the real world?

I can see that writing code in the form's class, hinders inheritance and re-usability in an OO world.

But i also see Access is not true OO and the IDE features give you the ability to do things not available in standard VB or OO design.

I guess I just need to see what can be refactored and turn form code into classes as appropriate.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[JoeAtWork]

There is nothing wrong with the methodology you are being taught, it is the correct way when you are building an application.

But when you are working in Access, you are not really building an application, you are extending one that already exists (Access itself). Theoretically you could achieve the Model/GUI separation by using unbound forms, but if you take that approach there really isn't much point in using Access forms at all. You might as well use VB or one of the .NET languages to build your application.

I can see that writing code in the form's class, hinders inheritance and re-usability in an OO world.

Yes it does. The typical Access "application" blends the business rules into the GUI code. This greatly hinders scaleability and reusability. As one example, consider having to migrate your "Windows" app to become a web app. If you had used typical Access code, you would pretty much have to rewrite your entire application. But if you had written your Windows app in VB or .NET, and you had properly separated your code into layers (GUI, Business Rules, Data Access), you should only need to rewrite the GUI portion, while still using the original Business Rules and Data Access code as is.

I think my advice would be to ignore Access right now and continue to learn the foundamentals of good programming technique. If you do, you will be way ahead of the many Access "programmers" out there who are really just amateurs to the craft.

In "real life" sometimes you need the fast easy way to get something up and running ASAP, and other times you need to use a proper methodology to create a quality app. Best to learn the quality approach first, after which the "fast and easy" will come very easily.

 

[MichaelRed]

OUCH!



MichaelRed

 

[1DMF]

Best to learn the quality approach first, after which the "fast and easy" will come very easily.

too late for that, been using access for @ 10 years, been studying OO for 1 year!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts

 

[MajP]

As MS Access is not true OO and has many limitations such as no contructor, is it not possible to code applications using the same principles I am being taught on my VB course?

Yes definately, but you cannot take the concepts to the extreme. I know you and I have been discussing this on another thread. Like you said it is an application, but a lot of the principles apply. I was taught Java before I learned Access, so a lot of the OO paradigms were drilled into me. If you look at my apps compared to many other developers you will see I provide twice the capability with half the amount of code.
1) I use custom classes extensively. This allows me to extend the functions of controls forms and other native classes. All my common functionality is contained in a reusable class. I write it once and then can be reused at any time simply by instantiating. I have demonstrated this in the FAQs with
find as you type comboboxes / listboxes
to from list boxes
"bound" Treeviews
Faq702-6304
Here is a recent one. It is a little bizarre, but if you ever want a tab control to fit to the controls on the current page then you can instantiate that capability with two lines of code.
thread702-1633737
2) Understand that form and report modules are class modules. You can extend their use by multiple instancing them, just like any other class
3) I rarely have code in event procedures (This is more good programming than specific OOP desingn). Most of my events call standard functions that can be reused or instantiate/use a custom class. Most of these functions are passed the form or control object as a parameter. So I write very little new code I just reuse my classes standard functions/procedures. As you know:
Thread181-1630893 (BTW this shows how to fake a constructor in vba)

I have seen some people try to take these concepts to the extreme, and end up trying to rewrite standard sql and recordset functionality. I think in concept the application does seperate the data model from GUI.

 

[1DMF]

I just wish I had a working version of Access at the moment, agghhhh 2010 you suck!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts