×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Aaron wrote:
For example, I have a lot of my DAO's (Data Access Objects) make their way
to the View layer even though a purist might say you should never allow an
object based on a table to make it's way to the View.
Don't know what you mean exactly with "make their way". But if you mean that your DAO's are "seen" by the view layer thats no problem. The view "knows" about the DAO's. Knowing what API to use to get to the data that is to be displayed is still a "view" concern, so to speak. But it does not know about or cares how that data is retrieved/stored/etc. But the more technical data access layer, the DAO's, never knows about any view (or interface thereof). Because the concept of "viewing" has nothing to do with how and where to retrieve data. But a DAO does now about what underlying database is used, for example, and what SQL to execute.
Not implementing a model layer is in itself not a problem. If your app is simple enough. It depends on the situation. That's why it's important to note that MVC simply an specific application of "separation of concerns". Or, we could simply call it modular programming. But - like all else - don't try to apply it too dogmatically. Try to separate concerns. Create modular code. I.e. a module (or procedure or subr or do-enddo block etc) must only do one thing. And do that one thing good and complete. A piece of code has to be concerned with one thing only, and nothing else. This applies to all of the software, horizontal/vertical, and large scale / small scale. MVC is the largest scale you can get, and it's vertical (layers). A layer itself is also divided into separate modules. For example in the view layer there is one component which is only concerned about processing all input events. It doesn't do anything else. It knows about the event queue and how to read it and how to process the events. It knows nothing else. There maybe another component who knows about the keyboard, and the different keys and their meanings and handles the keyboard events. It knows nothing about a "event-queue". It only nows ther are "keyboard" events happening that must be handled. The event queue processor doesn't know anything about keyboards. It knows about events in the event-queue. And it knows that it has to delegate the handling of "keyboard" events to the keyboard processor. Thats all it knows. And thats all it needs to know.
Date: Thu, 17 Jul 2008 10:56:32 -0500
From: aaronbartell@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] The "Presentation" Layer
I guess my point is that there's a natural tendency to blend everything
together. Even though you try not to. And I may not be able to pinpoint a
specific example, but I suspect there are a number of major vendors and
players in the UI widget market that have combined UI layout with data
validation and formatting, and mapping with data stores, into one component.
And maybe to jump on their side, it can *sometimes* be right if it proves to
create quick application development that is also easy to maintain
longterm. The contrast to separation of concerns is leaky abstraction which
isn't bad all the time (http://en.wikipedia.org/wiki/Leaky_abstraction).
For example, I have a lot of my DAO's (Data Access Objects) make their way
to the View layer even though a purist might say you should never allow an
object based on a table to make it's way to the View.
Anyhoo, so many terms, so little time to read about them :-) BTW, these are
terms I HAD to take an interest in because of JSF's flaws (of which I have
commented on here in the forums a number of times).
Aaron Bartell
http://mowyourlawn.com
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
_________________________________________________________________
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolie&FORM=MIINTM
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.