maybe I should check the 4.0 documentation ... but I'm working with 3.8.4 beta ... I've finished my BO's and am now integrating into a MVC solution .....
The mvc example does not check the Session Object to see if the current BO is of the type that is being broght into the View ..... In the WebForm world the examples checked to see if the bo being created / read / updated /deleted was of the same type as the bo in Session ...
Is that pattern passe with MVC ?? Pros ?? / Cons ??
When building a web app, whether MVC or not, you need to decide if your server will be stateless or not.
When I built most (all?) of the Web Forms samples I used a stateful server model - so Session was allowed.
Most MVC apps, in my observation, have stateless servers. So I've mostly been building demo/sample MVC code using a stateless approach.
But ultimately it is your choice.
ok ... so now I am trying to figure out how to pass a business object from one View to another .... I create my Customer on the opening page and want to send it to the customer.invoices page without having to re-instantiate ...
I'm working on the BO layer and my web designer is rather new to asp.net mvc ....
I assume it's feasible .... looking for examples on passing a model from one view to another ....
having a variable in the Global.asax is one option, I assume ... any other patterns for this ???
is this an example of where MVVM would be relevant ???
You need to store the server-side state somewhere between server options. Navigating from one view to another involves at least one postback, which means the server loses all its state (by default) between calls.
Unless you put the object in Session it won't be there on the postback (the next controller action).
I would avoid using session as much as possible (you will see this the case in almost all MVC examples).
In your scenario, re fetching the Customer should be perfectly fine if you need the customer info again. Your URL would look something like this:
YourApp/Customers/1/Invoices/ <-- for a list of invoices for customer 1.
Really surprised that there is no way to pass a model (instance of customer) from from one view to another ... I really have to make another database call to see the same instance in another form ???
and about session ... I'll have to double check ( hard to load the Ptracker MVC demo on machine with MVC2 installed ) ... but what about keeping the CSLA Principal in Session for authentication and permissions ???
Is there a better approach for that ???
Well, depends what you mean. Is it a completely different view? Or is it a partial view? If it is a partial view, then yeah, what you are saying makes sense.
But you don't really pass models from views to views. The controller is what feeds the models to the views. Perhaps if you explain your scenario can help better.
And yes, you usually do have to make another call from db if you are on a different page. Remember, web is stateless (unless you store somewhere like in Session or the Db, which is what you are trying to avoid).
what about using WCF instance management to persist a list of business objects ?
I beleive that it is feasible to engineer a way to persist the in-memory CLR objects ( CSLA BOs ) for all web users in a List<BusinessObject> that is managed by a service outside of the users web session. So instead of re-querying the DB ( or in my case calling a 3rd party ASMX method ) ... why not cache DTO's or the BO's themselves behind a WCF facade ???
You probably should weight and really test whether caching will give you benefits in your scenario. You are calling a 3rd party web service, so maybe it would be best to cache if that is a really expensive call in your scenario. But I would test, before making the assumption caching will be the best as it brings its own set of complexity (like when to refresh, what happens if changes happen and data is still cached, etc...)
If you are dead set on caching, maybe take a look at Windows Server App Fabric (aka Velocity). Scott Hanselmann had a recent post on it:
xAvailx is right - premature optimization is an anti-pattern. If you don't know that you have a problem, don't try to fix the problem you might or might not have.
Copyright (c) Marimer LLC