New Posts New Posts RSS Feed: PrismExplorer questions
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

PrismExplorer questions

 Post Reply Post Reply
Author
Peer View Drop Down
Newbie
Newbie
Avatar

Joined: 31-Aug-2010
Location: Netherlands
Posts: 15
Post Options Post Options   Quote Peer Quote  Post ReplyReply Direct Link To This Post Topic: PrismExplorer questions
    Posted: 14-Sep-2010 at 12:43pm
Hi All,
Today I started evaluating the PrismExplorer sample as a part of the DevForce evaluation. After wachting the Teched presentation twice (on the left screen the video, on right screen the source code) , I have a few questions (and probably more this week) ;-)
 
Why aren't there viewmodel's for Employee and Customer ? (Customer isn't editable, but Employee is !)
Why is the employee logic in the ModelExplorer.explorer ? and not has ist own module like  CustomersOrderViewModel ?
Why is the CustomersOrderViewModel in a silverlightproject? shouldn't is be avaiable  for all UI's  ? 
Is this sample application a clear architectural sample how to implement Prism and DevForce ?
 
Is this an appropriate  project for a newbie or should I move on to other samples ? My goal is to make scalable Business applications so therefore the PrismExplorer seemde to be the right start.
 
Thanks, Peer
 
 


Edited by Peer - 14-Sep-2010 at 12:46pm
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338
Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 14-Sep-2010 at 8:06pm

All great questions. Let me begin with the end.

IS IT A TEMPLATE FOR BUSINESS APPLICATIONS?
 
That was not it's purpose. There are good ideas in there for anyone building composite applications. But it is not a roadmap for a business application ... and was never intended to be.
 
PrismExplorer was written at least two years ago about the time that Prism v.1 and Silverlight 3 were about to be released. As importantly, DevForce itself has matured in those two years. We were on DF 2008 (and then DF 2009) back then; we are well into DF 2010.
 
It's showing signs of advanced age. I would do much differently in DF2010 and SL 4. I'd be looking at Prism v.4 now even if it is early days.
 
Again, I'm not dismissing PrismExplorer. I'm asking you to learn from it without imitating it.
 
We created PrismExplorer first to show that DevForce and Prism work well together.
 
Second we wanted to show off some of the cool things that DevForce can do like all the CRUD stuff, an amazing variety of queries, PredicateBuilder, caching and offline, save and restore to/from isolated storage, etc.
 
Third, we wanted to use some important patterns like MVVM (relatively new concept at the time), Repository, Modularity, EventAggregation for cross-module communication.
 
It was never intended to be a demonstration of good architecture. It couldn't be. There was no business context ... no realistic problem to solve. No real application presents a single view that can present and edit any kind of entity; that's great for demonstrating DevForce ... and little else.
 
I think many of the techniques and ideas remain valuable and should inspire you. Just don't take it out of the box and start building on it ... please.
 
And most of all ... PLEASE do not duplicate anything we did in the views!  We wrote those in XAML back in SL 2 days before there was any tooling and many features we take for granted were not there. The DataForm and DataGrid showed up late.
 
NOT A BEGINNER SAMPLE
 
You probably want to learn a little DevForce before diving in. I don't think PE is all that difficult. But tastes and experience vary. You be the judge.
 
IS IT A CLEAR EXAMPLE OF USING PRISM AND DEV FORCE TOGETHER?
 
It is a clear example of how I'd have done it two years ago. Many of the structures remain sound and are carried forward in Prism v.4 recommendations.
 
But I'd change many, many things about it because of advances such as DevForce 2010, SL 4, Blend 4, VS 2010, Prism v.4, Behaviors ... so much has happened ... we all have so much more experience now.
 
Astonishingly, it is still better than 80% of what I see out there. But, please, proceed with your eyes open and ready to question everything.
 
Why is the CustomersOrderViewModel in a silverlightproject?
 
Composite applications are modular applications. One of the central themes in Prism is loosely coupled modules that can evolve independently of each other ... perhaps by different teams of developers. Such modules have their own internal components that would not be shared.
 
The story in this example, is that someone developed a module (CustomerOrders) dedicated to managing the orders of a single Customer. The main "Explorer" module doesn't know or care about this. It's doing its job of showing that it can present and edit any entity in the model.
 
Aside: Have you noticed that the CustomerOrders module only appears when you first query for Customer? That's the EventAggregator at work. Have you noticed that the CustomerOrders view ONLY fetches customer orders when that view is visible? That's intentional too. We didn't want to bog the application down, asking it to fetch customer orders every time you changed the current customer in the Explorer modules; after all, why pay the price of fetching order data if you can't even see the orders. These performance techniques are still relevant today.
 
The two modules - Explorer and CustomerOrders - are completely separate. For convenience, they share a common DevForce model; but even that is a curiosity and you might want each Module to have its own Model.
 
The fact that they share a common Model made for a convenient way to communicate about "Customer" from the Explorer module to the CustomerOrdres module via the EventAggregator. As I recall, we pass a Customer entity across (I really don't remember). I would advise against that kind of thing today; to say why would make this post even longer. In short, I'd rather that the modules have separate EntityManagers and communicate via the Customer.Id. 
 
That would have made some of the story I was telling about offline a little more difficult so I let the two modules share more than they should. Look again at the goals I had for PE ... and you may forgive me for cheating a little.
 
Why is the employee logic in the Explorer module and not in its own module?
 
When you click the Edit button for any other entity type you'll see an auto-generated DataForm for that type ... a form that is truly ugly.
 
We wanted people to see that it didn't have to be that way. That at least one of the entities could be presented and edited in a somewhat more attractive manner.
 
It was also an experiment to show how you could have a mix of generic View/ViewModel pairs and switch to a custom View/ViewModel pair when the "business owner" wanted something more tailored.
 
We wrote this part of the demo app back when there was only one module in the application, Explorer. The CustomerOrders module came later when we were ready to show how to communicate across independent modules.
 
Why aren't there viewmodel's for Employee and Customer?
 
We were making a point about View/ViewModels, namely that the VM need know only what is necessary to support the view. It shouldn't do more. It shouldn't be aware of what the view does.
 
What better way to make that point than to have a single ViewModel like FormViewModel ... which has a tiny API. Then show that one could build a rich View (the EmployeeFormView) to biring it to life ... or fall back to the uninspired FormView for everything else.
 
It really shows the power of separating visual design (the View) from the View-agnostic, developer-driven ViewModel.
 
Customer isn't editable, but Employee is (?)
 
Actually every entity is editable. You can click the edit button and change a fact about the Customer and save it. Only Employee has a nice form; the customer is edited through the generic DataForm.
 
Did you notice that you can edit any time but you can only add and delete Customers? Used an interface to make that work ... the Add and Delete buttons only light up if the entity implements the interface and the interface implementation also prescribes rules for adding and deleting. Such techniques might be useful to you. I'm not "recommending" them per se ... they're food for thought.
 
Again, our goals were to (1) prove that Prism and DevForce integrate well, (2) show off some DevForce features, (3) get you thinking about some more advanced patterns that are handy in a composite business application.
 
Enjoy!
 
 
Back to Top
Peer View Drop Down
Newbie
Newbie
Avatar

Joined: 31-Aug-2010
Location: Netherlands
Posts: 15
Post Options Post Options   Quote Peer Quote  Post ReplyReply Direct Link To This Post Posted: 15-Sep-2010 at 12:23am
Thank you very much for your clear and extended explanation. It helps me a lot in my overall view how to deal with Prism, te PE and of course DevForce  ... !!! Prism seems te be a good architecture for us.   This week I'll try to create  an EmployeeOrders module and then move forward to other samples.
 
Thanks again, :)
Peer
 
 
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down