Re: basic question..

[email protected] wrote:

>Firstly, let me apologise for posting such a basic question here, but since there isn't a users list it seems the only option.
>  
>
Hi Peter - no need to apologize. This is the only list, so you are 
asking in the right place. Welcome! :-)

>As far as I can tell in the examples, every time we handle a view event, we instantiate a new model object. Am I correct or have I overlooked something?
>
>Assuming this is the case, what sort of performance impact should I expect for a high traffic application?
>  
>

Well, with any event (control or view), you have to provide an 
_instance_ of the event handler. This means you can write code within 
those handlers that doesn't have to worry about being threadsafe (as 
long as you aren't accessing static or class variables). That also keeps 
the "weight" (footprint) of the webapp very light - basically, the only 
thing that sits in memory are factories to instantiate handlers. As 
events come in, the factories (which are threadsafe) spawn instances of 
handler objects to handle the requests. When the request is complete, 
those objects can be gc'd.

SO...within a particular handler (ie. a view handler), you typically 
instantiate a component (ie. BTemplate component to process the page), 
attach models to that component and then let the sucker render. 
Typically then, each event fired by a user request will end up getting 
handled by components/models that are their own objects.

Now I say typically because that's the easiest way to do it, and that's 
the way most of us probably go about things. But Barracuda does not 
require you to do that - you can easily have a "shared model" or a 
"model pool" - the only thing is, if you do this you need to take 
appropriate measures to make sure those shared objects are threadsafe; 
as long as every request has its own instances of the models then you 
don't have to worry about that.

So the bottom line is - the framework will let you do it however you 
want to.

Regarding performance, I don't think you're going to run into problems 
(at least not any more significant than any other web framework). I 
don't know what kind of traffic you need to deal with, but you'll 
obviously want to do some initial testing to make sure it meets your 
requirements (and if you run into problems, please let us know about 
them - I'd be very surprised if there are any fundamental scalability 
problems with the framework)

In terms of performance, I don't think you are going to get nailed by 
instantiating individual copies of models (unless those models are 
extremely expensive to create, or have a very large footprint).

In our experience, performance issues hinge around the DOM - basically, 
by using a DOM based template approach you end up having to parse the 
"template" a couple of times (which is obviously going to be slightly 
slower than something like Struts which is just reading the file and 
processing it as text). But this doesn't seem to be a huge hit in our 
experience (certainly nowhere near those approaches that use XSL 
transformations to convert from DOM to final output).

The second area is more significant - because the DOM has to stay in 
memory before it is rendered, if you have a very large page (say 30000 
rows of data), you are going to find your server running out of memory 
(of course, you will also find your client browsers barfing too on pages 
this large - its a factor of the DOM, not Barracuda per se). 
Fortunately, we have ways around this limitation, at least on the server 
side. Basically, you can use a BlockIterator component, which processes 
templates in chunks - and each chunk (corresponding to a row or block of 
data) will get parsed, processed w/ a BTemplate, and then rendered back 
to the browser immediately. So we use this approach for all of our 
reports where we could be generating thousands of rows of data. If you 
get to the point of needing some examples here, holler.

>Perhaps it's because I have never done any swing development, but my understanding of the 'model' in MVC was more along the lines of the business model which has a life seperate from the user interface. In this case, when I look at the DiscRack app, I'm confused about the way the actually objects 'contained' in the model are retrieved within the event handler which then instantiates the model and passes in these objects.
>  
>
Part of the problem with the term 'Model' in webappland is that it 
generally means something completely different than what it means in 
client-server land (like Struts).

Here are two links that may be helpful:
http://barracudamvc.org/Barracuda/docs/barracuda_vs_struts.html#CC_Flow_MVC
http://barracudamvc.org/Barracuda/docs/comp/mvc.html

The key point to realize is that Barracuda provides both Model 2 "flow 
control model" (event layer) and Swinglike MVC "component models" 
(component layers). I'm not aware of any other framework that really 
makes this distinction (but its been a while since I've looked).

>I'm fairly certain that I'm right in saying that I could have a seperate model class which would provide the facility for the event class to specify the 'query' details without actually ever handling the data objects (I'm thinking of using Hibernate in this context). This would seem to me to give a better seperation of M from VC.
>  
>
In regard to this last question, one of the biggest benefits of 
Barracuda is that it is cleanly layered. So you can use as much or as 
little of it as you desire. This makes it relatively straightforward to 
integrate with other technologies (provided they are actually layered 
well enough themselves).

Thanks for checking out the framework - please feel free to holler if 
you have further questions.

Christian

------------------------------------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com <http://atmreports.com>
------------------------------------------------------------------------

/"Coffee? I could quit anytime, just not today"
http://seelifedifferently.blogspot.com/