PrismExplorer questions

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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!