A very good friend just hung up on me in the middle of an IM exchange about whether “we” are over-hyping Prism and recommending it for situations in which it is overkill. He said yes; I said no.
Ok, he didn’t actually hang up on me; our IM connection failed.
I’m replaying our exchange … and because he bailed,however involuntarily, … I get the last word.
-----
Friend: [So-and-so] thinks that [some people] are starting to push Prism in cases where they shouldn't.
Me: Such as?
Friend: They are saying that anyone who builds line-of-business (LOB) applications with Silverlight should use Prism. He doesn't agree. He thinks that most of Prism is good only for Composite UI, with a few exceptions like delegate command, and the project linker. I agree with him. Prism is not the “end-all” for every solution.
Me: True ... but it's the right call for modular solutions. And the bootstrapper + Dependency Injection (DI) are pretty much central to anything I would build.
Friend: Anything YOU build yes. But I don't think you can assume that DI is a given. You can't make using DI a “must”. Sure, for composite apps it makes total sense. For TDD (Test Driven Development) and decoupling of components yes ... but I won't go as far as to say "you must".
Me: It isn't a “must”. Nothing is a “must”. But come on ... once you're comfortable with DI, you never want to be without it again. It is trivial to put in place, easy to use, and it makes writing single-responsibility code every so much easier. And testing, by the way, is NOT why I like DI. You get the major benefits of DI without writing a single test.
Friend: In general I agree but there is a bit of self-selection there. I mean DI appeals to you...and me, and others like us but that does not mean it is something that will work for everyone or that they will perceive the benefits.
Me: No, this is not a case of elitist self-selection. DI does benefit everyone. I think you do the inquiring developer a disservice by supposing that they will be unable to see the value. Look, if you don't want guidance ... if you just want to wing it, then don't ask for my advice. If you want guidance, than I say that something like Prism is good for you in almost any business application.
Friend: Huh? I would be careful if I were you. You’re starting to sound dogmatic.
Me: I'm trying to respond authentically to the developer who asks "how do I build an app?"
Friend: It sounds like you’re recommending a swiss army knife. I would be very wary of that!
Me: No, I don’t thing so. There are some standard problems in any business app ... and Prism ... or parts of it anyway ... and I include it's promotion of certain patterns ... Prism addresses those standard problems. DI is NOT a swiss army knife part. Neither is the bootstrapper. And every app has some kind of shell. These constructs are basic to just about any application.
The other Prism components you may safely ignore until you need them. You may not need Regions and Commanding and Event Aggregator during the first weeks. Not to worry. They are non-intrusive. They are waiting for you, quietly, causing no trouble at all. When you do need them, they’ll be ready for you.
Do you want to argue that the presence of unused components is indicative of a "swiss army knife” syndrome? You might as well say that WPF and Silverlight are swiss army knives because they have loads of features you will never use.
Friend: Not the same.
Me: I'm listening. Why not?
Friend: I don't think you can assume that every app must use modules. I don't think you can even assume the bootstrapper needs to be there. Why would I need a bootstrapper? I have Main.xaml as a shell.
Me: I didn't say every app needs modules. You could use Main.xaml as the shell. But what happens is that all of the other jazz that happens at start-up tends to be piled into Main.xaml or App.xaml. This practice is almost always bad. You’re combining the view that defines the application’s screen real estate with initialization logic; these are wildly different concerns. You really SHOULD think about how the application starts as as a thing unto itself. Failure to do so leads to trouble.
Friend: If I am not writing a Composite UI , why do I care?
Me: You care because the app.xaml gets out of control very quickly as more and more initializations mingle with the code to support how your application hosts it’s views. That is the “shell” function. I’m talking about all of the little services you’ll need – logging, authentication, authorization, persistence, email - you want to register them somewhere. This is bootstrapping, not view hosting; these start-up activities belong in a dedicated class.
And if you're NOT thinking in terms of these services – if you’re thinking you’ll introduce these capabilities by “new-ing” up classes or referencing singletons wherever you need them – you’re heading straight for the kind of hopelessly entangled, brittle application that gets progressively harder to maintain and evolve.
Friend: You realize you do come off a bit biased don't you? I know everything you are saying and am being a bit of devil's advocate.
Me: I realize I am talking to you and so I can make some aggressive claims in my argument without serious risk of contradiction. I don’t think my present approach will persuade the uninitiated. But I resist the notion that I am being “biased”. By charging “bias” you are suggesting that I am somehow an unthinking captive to an ideology. That’s the easy, simplistic way to dismiss advice of any kind.
It is not just a “bias” when I tell you that maxing out your credit card with no ability to pay puts you on the road to trouble.
I see a lot of applications. I see a lot of applications go wrong. They tend to go wrong in the same way over and over again.
The concepts that Prism fosters help you find a way out of those familiar mistakes.
Friend: look I am not saying Prism is bad ...
Me: And I will agree that it is not a magic bullet.
But it is more than a collection of components, more than a bag of tricks. If it were only that, you could argue that the tricks were needed only for applications of sufficient sophistication.
I think Prism is something completely different. I think it is is a lens that helps us see farther and more clearly. Through that lens we can find solutions to the problems that would otherwise mire us in the half-measures that gradually slow our progress and make our code stink.
And, by the way, when I say “Prism”, I mean it to stand in for any such ensemble of guidance and infrastructure code. What Prism-like thing you actually use could come from anywhere; you could write your own. The Prism that comes from Pattern and Practices is just an instance of what I have in mind.
Instant Messenger: Your friend signed off at Wed May 27 01:36:30 2009. This user is offline. Your messages will most likely *not* be received!
Me: Grrrr
------
Feel free to chime in yourself.
13 comments:
I had a user group meeting where we were talking about similar topics.
Point that I made: if you can rewrite the app in under 4 hours, then I don't care what design patterns you use.
But, #1 don't be afraid to throw the code away, #2 expect to throw it away.
I also hate the "bias," "personal preference, " and "dogmatic" arguments against inversion of control. Is quality, maintainability, and easy testing a personal preference? If we use those as standards to judge whether certain practices are good or bad, I think it's easy to make an objective argument that designs that Prism promotes (fair to call them SOLID?) are better.
It's funny to see the "swiss army" shot at Prism by someone who promotes using Main.xaml as their shell. I understand being a devil's advocate, but... maybe he was just pushing your buttons?
This argument will come up every time we as developers start eyeing the next level of abstraction. For example, we use MS CRM as a framework to run our entire enterprise - our internal apps, our public website, our B2B vendor feeds and portals, everything.
At the risk of sounding like a CRM salesman, this framework allows me to create a new entity (table) in a web UI in just a few minutes. Behind the scenes, CRM builds the database tables, builds a few views for Reporting Services, builds a new default web form (to which I can add JS or IFrames for extreme customization), updates the WSDL for the web service to expose this new entity (Update Web Reference in VS), and several other things that I don't have to worry about anymore. From there, we use a 3rd party code generator that looks at the CRM metadata and generates objects that are simple to use from Web pages, console apps, Winform apps, etc. CRM also has a built-in workflow engine (using Windows Workflow Foundation of course) to which I can add custom workflow activities built in VS using our code-gen'd objects. Finally, I can do almost all of this in a live production environment 10 minutes after we have the meeting where Marketing wants to add a few more fields to a web page.
CRM allows me to truly concentrate on *only* the business logic. I will absolutely say I am biased because after a year of building on top of CRM, I know that I can build anything else on top of it as well.
I am not trying to compare Prism to CRM because they are obviously completely different technologies, but all that to say this - Ward is an expert on Prism, just like I'm an expert on CRM. Call it bias if you like, but experts *know* they can build anything with their solution of choice. Experts also *know* to move to the next level of abstraction when the benefits finally outweigh the loss of granular control and the learning curve.
I work with a similar framework. While I don't have as many options, especially on the code-generation side, I'm also able to add fields to a live environment ten minutes after the request was made. And the majority of the time, everybody will be very happy with the modifications. Does that mean that I do it? No. I used to, but it's boomeranged on me so many times for so many years that I won't do it any longer.
If "building something" constitutes just getting the thing up and running and people using it, then it is true that many solutions will work. But change always comes to *all* software that's being used, whether it's built with Prism or anything else. And when it comes to handling that change, some frameworks are definitely much better than others. If MS CRM and your code-gen tool are built on the same change-handling ideas that Prism was built on, that's great and keep using them. But if they're not, I'd be really careful.
One other thing, too.... I don't see the cost in moving to more modular, dependency-injection type of solution. Switching to that type of development didn't change the code I wrote so much as it forced me to organize my code properly. I totally understand why someone wouldn't use Prism, but the ideas behind it definitely should be incorporated as much as possible.
Excellent points - and again, I'm not comparing technologies, I'm just trying to make the point that "bias" is a card often played by people who don't fully understand the awesomeness of the technology. :)
In fact, I see Prism/Silverlight as completely complementary to CRM - that's why I keep up with this blog. We haven't gotten there yet, but eventually we will be building Silverlight pages that talk to the CRM webservices as their datastore.
I was also initially wary of changing fields/entities, workflows etc on the fly because of the "boomerang" effect you mentioned. But I've learned to "trust" the system because of all the checks CRM puts in place. For example, if I try to delete an attribute on an entity, CRM won't let me if it finds that the attribute is used on a workflow, or a report, or a web form, etc. I can also code-gen our objects without that attribute and rebuild our entire code-base to see if anything breaks. And of course we have a dev system in place to test new workflow activities or anything else if necessary.
The other really nice aspect of CRM is that it is a standard system. We can hire a "MS CRM guy" and he can be up and running in days after learning our data model - he doesn't need to learn a proprietary framework before he's useful. And of course the 3rd party space is very active - for instance, I'm about to add field-level auditing to all entities in CRM by just installing a free add-in from CodePlex.
I slipped into Salesman mode again, but my original point is that the words "bias" or "swiss army knife" don't bother me, and in some cases I'll actually take them as a complement. :)
The exchanges on CRM (and other productivity tools) all interest me.
I don't know about you folks but I use Excel for many "applications" because it is the right tool for those jobs. It would be silly to comment about all the things it can't do or my "application"'s eventual collapse in the face of emerging business requirements. Like "Duh". But it does the job ... and while it does the job ... which may be forever ... It kicks butt.
I don't intend to diminish the power and scope of MS CRM when I say this. I picked Excel precisely because none of us is tempted to think of it as application dev framework. And yet there it is ... performing its small miracles for businesses everywhere.
I have not doubt that an enormous number of business apps are well met with the MS CRM-based approach; you would HOPE so in light of MS investment.
I wonder if anyone would say that MS CRM is the appropriate foundation for, say, a payroll system or staffing system, or a trading desk. None of the CRM metaphors as I know of them fit terribly well here.
So, if the higher level of abstraction afforded by the MS CRM stack is not appropriate, where do we go?
We don't race for the bottom. We look to things like Prism. And the point of my post is that there are a great many applications - even simple ones - that can be well served by Prism ... and similar infrastructure solutions.
OK, I'll let the cat out of the bag, it was me that started this whole thing.
I am a huge fan of Prism. It was an awesome project to be a part of, and I am happy to see that people are finding success with it.
However, I worry when anything becomes a silver bullet. Solid is a great principle, IOC can be wonderful, however I don't think Prism is the magic answer for everyone who want's that. And I do think that using Prism (as light as it is) CAN be overkill in many cases. We called it out in our documentation, because we believed that.
Prism was designed for building composite applications. We designed it with the intent of making it broadly applicable, and maybe we did a better job than I thought. However, I don't want people to think that if you are being LOB applications, that means you MUST use Prism, that would be an abuse of the guidance we delivered.
As far as @Darren's comment. You can use Main.xaml as a shell, with Databinding as a mechanism for pulling content into it. This is not far-fetched, it is completely realizable.
Glenn
Damn, Glenn! I thought I'd get the last word ... at least on my own blog :-)
Thanks for chiming in.
Being first inspired by applications like the Eclipse IDE, GAIM (now Pidgin), Trillian, and Miranda, I've been building composite LOB applications for about 5 years. First building my own Web client framework, then using CAB, then working with Dell on their home-grown framework started by David Hill, and now with Prism.
I agree that composite architecture may be overkill for the uber-simple applications, but out here in the wild I feel that most applications are complex enough to warrant considering a composite approach. I'd say that if there are more than a few vertical concerns in an application then its worth the effort.
That said, the framework you choose has an impact on this decision. CAB was fairly heavy and intrusive, so I would have recommended it for fewer projects than I would for Prism.
Glenn,
I agree that we do not want to oversell Prism. This is a healthy debate and should continue so the community has a better understanding of when and when not to use the Prism patterns.
I am providing a counter argument. I had a customer tell me that Prism helped this person on a project team of one person. It enabled the project to be more maintainable from the start and he could more easily respond to feature requests by his customer in V1. By the way, I hear lots of comments about people's success using Prism.
What would be great to hear is what scenarios people used the Prism patterns and they did not find benefit. What did they learn from the experience that can be helpful to others.
This information would be very helpful to the Prism team as customers are constantly asking us when and when not to use Prism.
Thank you Ward for starting this discussion.
Blaine
I continutally here success stories on Prism, and I have yet to hear any signficant negative feedback, yet I have come across folks who say it is overkill, including the WPF disciples.
If Prism works for customers they should definitely use it. My point is that it is not a silver bullet, and someone should not automatically assume for ANY LOB app they are building that they MUST use Prism.
@Blaine - it WOULD be fascinating to learn if Prism FAILED anyone. I haven't heard any horror stories yet. And, yes, it works great for the lone developer.
@Glenn - No Silver bullets for sure. I wouldn't say Prism is the only such game in town. Nor does it cover all the things you need to do to make your LOB app. And no one needs to tell YOU this :-)
But it does address concerns that just about any non-trivial LOB app will face: modularity, eventing, commanding, bootstrapping, ... perhaps even view composition. Show me the LOB app that is free of these concerns.
If I had Prism (or a solid alternative), why would I ignore it and roll my own?
I'd only do so if I thought I could do better ... way better.
Glenn: Ditto on Silver Bullet.
Ward: Big ditto on "If I had Prism (or a solid alternative), why would I ignore it and roll my own?
I'd only do so if I thought I could do better ... way better."
Here is why. I heard of a customer doing an experiment between 2 different teams - one used Prism and the other did not. They were much happier with app that was built using Prism because it was architected and designed better than the application that did not use. The bottom line is there is a consistency on how the solution is built with Prism or something like it. The approach has been successfully used by a number of companies to build apps.
Post a Comment