Brian Lagunas

Brian Lagunas Brian Lagunas
MVP Logo

Niner since 2010

Brian Lagunas is a Microsoft MVP, a Microsoft Patterns & Practices Champion, Director of Technology for INETA, co-leader of the Boise .NET Developers User Group (NETDUG), board member of Boise Code Camp, speaker, trainer, author, and original creator of the Extended WPF Toolkit. He is a multi-recipient of the Microsoft Community Contributor Award and can be found speaking at a variety of user groups and code camps around the nation. His talks always involve some form of XAML, such as WPF, Silverlight, and Windows 8, as well as how to build modular applications with Prism.


  • Implementing ​Navigation​Service for Xamarin Forms and MVVM

    @HoussemDellai Thanks for the great video. Keep up the good work.

    @steven: You have to register your types with the container in the RegisterTypes method in the App.cs.

    Example: Container.RegisterType<IMyService, MyService>();

    You might consider making them a singleton if possible.

  • The Xamarin Show 10: Prism for ​Xamarin.​Forms with Brian Lagunas

    @alex: Thanks for your feedback.  Unfortunately, there are a number of issues with trying to support a fluent API like you are suggesting.  For example; your desire to navigate to a concrete Page type breaks the MVVM pattern.  So, I would never consider doing that.  Even if you had the ability to navigate to a Page concrete type, you could not do deep linking with this API.  The process of building up a complex navigation stack using this API would not be possible.  In the end, this is just an coding style preference.  You do not gain anything substantial from using it.  Essentially, you are going through all this trouble to avoid using a navigation URI, which goes against the entire reason for using a URI based schema.

  • The Future of the Prism Library

    @BabbleBits: Thanks for watching and I am happy to hear you are finding value in Prism.  Yes, I didn't mention the Events folder in the demo due to time constraints.  Also, just a heads up, the PrismEvent class is being renamed back to PubSubEvent.  So when you upgrade to the next version, you can expect to go rename PrismEvent in your projects.  Be sure to let us know what features we need to be thinking of or adding as you use Prism for Xamarin.Forms.

  • Looking Through a New Prism

    Be sure to check out the new Prism for Xamarin.Forms Preview on NuGet:

  • MVVM Best Practices

    @Mythgarr: Yes and no.  A pattern is doing nothing more than giving a common name to a development approach that we use every day so that when we talk about it, we all know what we are talking about.  So if you are saying you use MVVM, but in actuality you are using Façade, then there is a possibility for a miscommunication.  Also, while there a technical difference based on the pattern definitions, there are also functional differences.  For example, you would not want to be creating commands in a façade object, but instead only in your ViewModel.  By identifying your object as façade, you can more easily add validation and logic to it that can be shared, without impacting existing Views, or worrying about adding custom logic for any particular View.

  • MVVM Best Practices

    @DanGarkusha: It's not open source, but I am always willing to share my experiences and approaches to creating software.  Currently, I am working on a "What's New in Prism 5.0" Pluralsight course, then I will be doing an "Advanced Prism" course.  After that, I will be doing a "Practical Prism" course, where I will cover most of what you are asking for.  An end-to-end application built from File -> New, all the way to deploying the application.

  • MVVM Best Practices

    @LeeCampbell: Most definitely!  Once we understand what MVVM is and isn't, let's learn how to apply it, and use other patterns and design principles to create a complete application.

  • MVVM Best Practices

    @Si1ver1ock: It's important to realize that patterns are not standards.  I think most software developers will agree that flexibility in any framework, tool, or library is a must if it is to be used in a wide variety of development projects.  Everyone's standards will be different, because every development team has different ways of writing software.  Development standards are the responsibility of the dev team, and will vary depending on the type of application you are writing.  If you want standards, create them, document them, and then use them when writing all of your applications.  Just be aware, that your standards will change over time.  As you learn new things, or new approaches, or new technology is released that help solve a problem, you will update your standards to fit your technical skills, and development processes.  This doesn't mean you have to rewrite your existing applications to use your updated approaches to writing software, it just means you have learned something new and have grown as a developer.

    I think your statement may be a little over the top.  Anyone that looks at my WPF Prism apps will have no problem figuring out how things are wired, or laid out, out because I use common patterns, and development practices, that most experienced developers are familiar with. 

    If all you are looking for is for someone to tell you how to structure your applications and write your code, then just ask a developer you respect for their opinion.  I will tell you how I do it for just about every WPF app I write.  I have my own set of project templates that I created that are unique to the way I write applications.  I don't publish them publically because I realize that not everyone likes to do things the same way I do.

    I personally hesitate to even use the word standard, as that implies that I have to abide by, or be locked into, some type of hardline approach to writing software.  I prefer to use the term guidance.  I provide guidance on writing successful WPF Prism applications, but the option is always available to go outside that guidance to solve a unique problem, or to implement a feature that doesn't fit, or have, guidance to begin with.

    Just my 2 cents.

  • MVVM Best Practices

    @BigCountry: A while back, I started writing a book. I got 55 pages in and decided books aren't for me.  I don't have the time or patience to write a book.  Now videos, that's a different story :0)

  • MVVM Best Practices

    @TedM:  Sorry, but I completely disagree with you.  It has nothing to do with "quick and dirty".  There is absolutely nothing wrong with having code-behind in a predominately MVVM application.  It's not about learning more XAML, it's about solving problems and being pragmatic when necessary.  One issue is when people try to delegate a View responsibility to a ViewModel, where it doesn't belong.  Sometimes it is necessary to place code in the code-behind.  What is your technical argument for not placing code in the code-behind?  Testability? Maintainability? Extensibility?  Sorry, you can still place code in the code-behind and accomplish all of those elements of development.  Just don't reference any concrete implementations.  For example, if you needed to call a method in your ViewModel from code-behind, do it through an interface.

    (DataContext as IViewModel).DoSomething();

    This code still delegates the action to the ViewModel without referencing it, it is still maintainable, and it is still testable.  A pattern is just a name we give something we do often to solve a problem.  MVVM is not law.  It's a pattern.  Principles are great to have in life, but principles can become very limiting, and costly, in software development.

  • MVVM Best Practices

    @DSaylor - Actually, Prism is not an MVVM framework, and before the release of Prism 5.0, had no built-in MVVM classes (though DelegateCommand can be argued).  Only recently, did the Prism team ship the new ViewModelLocator support, which still doesn't constitute an MVVM framework per se.  At it's heart Prism is guidance for creating composite/modular WPF applications.  So Prism sits at a higher level than just MVVM.  It is more about the architecture of your entire application rather than just your View development patterns.  You can use any pattern you like with Prism; MVC, MVP, code-behind, and it is not dependent on MVVM.

    Also, with the new 5.0 release of Prism, the various functions have been separated into separate libraries that can work independently of each other, and are not required to be used as a whole.  So if one app needs modularity, and nothing else, then it will use the Prism.Composition.  If your apps just needs event aggregation, then use Prism.PubSubEvents.  If you only want ViewModelLocator and DelegateCommand use Prism.MVVM.

    I will have to admit, the new Prism.MVVM NuGet package can be argued as a framework, but it is not required for use when writing a Prism application.  I still don't use ViewModelLocator in my applications.  Although, it is starting to grow on me a little bit.  So as far as my statement "I don't use MVVM frameworks", that still holds true.

    I hope this helps answer you question.

  • Infragistics Controls for XAML Developers

    @Andrii: No one knows why Microsoft does the things they do or don't do.  A WP FlipView is a control Infragistics can write.

View All