WPF/.NET data access models - resource recommendations_问答_开发者

We're in the early design/prep phases of transferring/updating a rather large "legacy" 3 tier client-server app to a new version. We’re looking at doing WPF over Winforms as it appears to be the direction Microsoft is pushing development of the future and we’d like the maximize the life cycle/span of the apps. That said during the rewrite we’d like to make as many changes to our data access/presentation model to improve performance as much as possible up front as many.

I’ve been doing some research along that vein but the vast majority of the resources I've found that discuss WPF focus only simple data tracking apps or focus on the very basics UI design/controls. The few items that even discuss data presentation are fairly elementary in depth.

Are there any books/articles/recommended reading/other resources recommended for development related to large enterprise level business apps?
Any “gotchas” that should/could be avoided?
General ad开发者_如何学Pythonvice to minimize the time underwater

I've been developing a large enterprise-wide WPF application for almost 2 years. As with any UI development, it's important to understand the best UI design pattern for the particular technology you are using. From my experience with WPF, the Model-View-ViewModel design pattern is the most prevalent. Once you understand the data binding powers of WPF, it is easy to see why a pattern like the M-V-VM is so accepted. Even if you don't follow the M-V-VM pattern (or a variation of it) word for word, understand the big picture solution that the pattern addresses. Basically, keep your UI/XAML file (View) in a separate file and all the code-behind/logic (ViewModel) in another file. The View simply reacts to changes in the ViewModel.

Keeping the ViewModel separate, you'll have several benefits.

Easy to create automated tests for the ViewModel object because there are no graphic components in it. It's just an object with methods/properties.
Easier to split the work up between developers (e.g. one developer builds the View while another developer is building the ViewModel).
It's much easier to use multi-threading in the ViewModel since it never interacts directly with UI controls. You know what I mean if you ever tried updating a textbox on a background thread.

Below are some of the pros/cons of WPF vs Window Forms from my experience:

Pros:

Much better UI appearance and experience to end users. WPF allows you to have ultimate control of the appearance of any UI element. (e.g. a list box that contains a picture/button/text for each row).
Data binding is amazing. Binding your UI controls in the XAML file to point to specific properties on your ViewModel class, and everything just works. The UI simply responds to any property changes of the ViewModel. Complete separation! You'll really see the benefit of this if you ever want multiple windows/user controls to display the same information simultaneously and automatically keep in-sync.
Everything I've read on MSDN is that Microsoft is putting much more resources into WPF than into the old Window Forms.

Cons:

Big learning curve. Don't be surprised if it takes a couple months before developers with no prior experience with WPF make a somewhat sophisticated UI. It's a brand new technology and there will be a learning curve.
Some common user controls weren't developed by Microsoft yet (e.g. masked textbox, data grid). However, Visual Studio 2010 does come with a data grid and it works well. Also, there are plenty of 3rd party controls on the market.

The best resouces I can think of:

"Pro WPF in C# 2008" - This book is awesome. It's over 1000 pages. It covers almost ever area of WPF. Use it like a reference book. It's straight to the point with easy to understand examples.
Link to Josh Smith's article on the Model-View-ViewModel pattern: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090016

Like I mentioned earlier, don't get too hung up on someone's version of the M-V-VM pattern. More imporantly, understand how WPF allows you to easily create a ModelView and have the View automatically respond to changes.

Good Luck! You won't regret WPF if you can get past that darn learning curve.

The VS2010 team has kept a blog about obtaining good performance as they switched to WPF.

They have a series, WPF in Visual Studio that offers a few suggestions (especially the second part).

General advice to minimize the time underwater:

Learn data binding as soon as you possibly can. Use data binding in every single prototype you make. Even if all you're doing is playing around with how panel layouts or grid splitters work: put an XmlDataProvider in your window, create XML test data, and bind to it. This is especially useful if you're using Kaxaml to prototype. I don't know how important that's going to be once VS 2010 is in your hands, but if you're using VS 2008 Kaxaml is invaluable.
Read Bea Stollnitz's article on how to debug data binding in WPF. Set your VS environment up so that you can always see the Output window while you're testing your UI.
Use MVVM and data templates from the very start. Pretend that code-behind doesn't exist, and that the only way to interoperate between the UI and the data model is through data binding and commands. You'll back away from this position pretty quickly, but if you make yourself learn this from the jump you'll find everything you do easier.
Pretend that your application needs to be able to run on a 36" widescreen monitor and a phone. Will you use fixed font sizes and measure things to the pixel? You will not.
Learn about the Grid's shared size scope and star-sizing. Those two things mean that you're going to use the Grid everywhere. The answer to the question "How can I get this element to use half of the remaining space on the screen?" is: with a Grid. (However, the answer to the question "How can I get this element to use all of the remaining space on the screen?" is: with a DockPanel.)
Be aware of the fact that WPF is not mature technology, and of the implications of that. It's not that it's buggy (it's not, though there are bugs) or has inadequate functionality (again, there are issues, but not often critical ones): it's that there are a lot of how-to-do-X-in-WPF articles and blog posts that were written before we really knew what was maintainable and what isn't. Validation's a great example. You can find no end of explanation of how to set up validation rules and attach them to bindings. You might not quite so readily find posts written later about why in most real scenarios you want to use IDataErrorInfo. Be even more hesitant about accepting the first answer you find than you normally would.
If you think that composability and dependency injection are obscure architecture-astronaut concepts with little application to real-world software development, get your head straight.
Don't freak out about how complicated dependency properties are. They can do a ton of things, but as a practical matter all you need to think about at first is change notification and value inheritance. Change notification requires a property setter to do something; that's built into SetValue. Value inheritance requires a property getter to do something; that's built into GetValue. The fact that property values can be either local or inherited means that instead of values being stored in fields, they're stored as dictionary entries; if a given property doesn't have a local value (i.e. there's no value for the property in the DependencyObject's dictionary), the DependencyObject looks to the parent to get its value. The terminology's really verbose, but the ideas are very straightforward.

I found this resource that provides several excellent examples.

Microsoft All-In-One Code Framework

Microsoft All-In-One Code Framework delineates the framework and skeleton of Microsoft development techniques through typical sample codes in three popular programming languages (Visual C#, VB.NET, Visual C++). Each sample is elaborately selected, composed, and documented to demonstrate one frequently-asked, tested or used coding scenario based on our support experience in MSDN newsgroups and forums. If you are a software developer, you can fill the skeleton with blood, muscle and soul. If you are a software tester or a support engineer like us, you may extend the sample codes a little to fit your specific test scenario or refer your customer to this project if the customer's question coincides with what we collected.

Today is March 12th, 2010. The project has more than 360 code examples that cover 24 Microsoft development technologies like Azure, Windows 7 and Silverlight 3. The collection grows by six samples per week. You can find the up-to-date list of samples in All-In-One Code Framework Sample Catalog.

http://1code.codeplex.com/

Consider looking into using the MVVM pattern.