Open new Window from ViewModel in WPF MVVM

Rav! Srivastava. CodeProject. 2016-10-02.
Implementing Factory design pattern to open new Window from ViewModel in WPF MVVM.
I got several question posted on web “How to open new window from view model in MVVM pattern” and I have also encountered the same problem  at beginner level  after googling and learning design pattern got the solution of this problem  and  decided to write an article with deep discussion. In this article we are going to implement the Factory Design Pattern. It will provide a flexible and loosely coupled environment.

[Open new Window from ViewModel in WPF MVVM]

Architecture Spinoffs of UXDD

Dino Esposito. MSDN Magazine. 2016-02-01.
Years go by and I’m just happy if I know and can recommend one or two effective ways of doing most software things. Don’t let the emphasis of software marketing fool you. Software improves constantly, but software is not the core business of most companies out there. This means that it’s more than acceptable for companies to keep using the same software for many years. According to the Tiobe.com index, in the summer of 2014, Visual Basic 6 was still in the Top 10 of most used programming languages. A year and a half later, it dropped quite a few positions, however. This seems to confirm the trend that the silent majority of companies tend to postpone full rewrites of software as much as possible. Realistically, the silent majority of companies have at least a five-year backlog in software technology that’s still running in their businesses. But when it’s time for companies to update those backlog systems, architects will look for state-of-the-art software.

[Architecture Spinoffs of UXDD]

Better Architecture with UX-Driven Design

Dino Esposito. MSDN Magazine. 2015-11-01.
The design and engineering of any software system begins with a well-known step: collecting requirements from users. This usually involves several meetings and interviews with customers and domain experts. Following the last meeting, nearly everyone involved in the project should believe that all details of the system have been ironed out and development can safely start. No one should doubt that the final product will be different from what was explained and understood. Customers should be happy and architects should believe they know exactly what to do.
However, in practice, experience shows that agreeing on abstract requirements doesn’t guarantee successful implementation. When customers actually see the prototype, more often than not they just don’t like it. No matter all the meetings and discussions, it seems that customers and developers form distinct ideas of the final product. Developers receive requirements and build the software around them. But the final product often misses the mark of what users want.
I think developers often tend to aim for functional completeness and don’t focus enough on the business processes end users need for the system to perform. So while functional aspects of business processes are captured, the overall implementation is rarely as polished and smooth as expected. In this article, I’ll present a design approach that can improve the chances for architects to build the right thing the first time. I call this approach UX-driven design, or UXDD for short.

[Better Architecture with UX-Driven Design]

Better Architecture with UX-Driven Design

Dino Esposito. MSDN Magazine. 2015-11-01.
The design and engineering of any software system begins with a well-known step: collecting requirements from users. This usually involves several meetings and interviews with customers and domain experts. Following the last meeting, nearly everyone involved in the project should believe that all details of the system have been ironed out and development can safely start. No one should doubt that the final product will be different from what was explained and understood. Customers should be happy and architects should believe they know exactly what to do.
However, in practice, experience shows that agreeing on abstract requirements doesn’t guarantee successful implementation. When customers actually see the prototype, more often than not they just don’t like it. No matter all the meetings and discussions, it seems that customers and developers form distinct ideas of the final product. Developers receive requirements and build the software around them. But the final product often misses the mark of what users want.
I think developers often tend to aim for functional completeness and don’t focus enough on the business processes end users need for the system to perform. So while functional aspects of business processes are captured, the overall implementation is rarely as polished and smooth as expected. In this article, I’ll present a design approach that can improve the chances for architects to build the right thing the first time. I call this approach UX-driven design, or UXDD for short.

[Better Architecture with UX-Driven Design]