We Keep Coding

What is the purpose of ReactiveUI's IViewFor<T> (and its implementing types) in WPF? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am in the process of learning ReactiveUI and so far I love it but I now realise that the framework encompasses XAML (i.e. the view layer) as well, offering things like ReactiveUserControl and ReactiveView.
Why do I need, or want these? System.Reactive/ReactiveUI offer massive advantages on the Model/ViewModel side but what are the advantages on the View side, again, in the context of a WPF app? Unit testing perhaps?
Note: I like WPF, I like its data binding. All my XAML bindings are strongly-typed and easy to refactor, customise, re-skin, debug and whatnot. I learned to use but not over-use the converters so never have a prob with those either. I never felt a need to override the UserControl class. With that said, I never had a problem with the WPF itself.
If I decide to use the IVIewFor<T> implementations, will my XAML designer go nuts? Will I lose anything? Will I end up debugging memory leaks, UI stutter and strange CPU spikes? We'll be making a very large app so we go by the 'better safe than sorry' principle as we were burnt by the CAB framework before.
If I decide against, what benefits of the ReactiveUI will we lose? Would I be heathens for doing this, or is it more of an optional aspect of the framework?
So far I understand the benefits in case of WinForms or Android (it offers binding support as I understood) but not WPF. While it sure does have its quirks, I don't feel the need for another framework on top of it.

You would implement IViewFor<T> when you for example want to set up bindings in the view and when you want to handle activation and deactivation, e.g.:
this.WhenAnyValue(x => x.ViewModel.Name).BindTo(this, view => view.Name.Text);
this.WhenActivated(d => { /* do something */});
These methods are implemented as extension methods. Please refer to the docs for more information and examples:
https://reactiveui.net/docs/handbook/data-binding/
https://reactiveui.net/docs/handbook/when-activated/
Of course you don't have to use all features of ReactiveUI. It's perfectly fine to set up bindings in the XAML markup as usual and still bind to ReactiveObjects.

Using the MVVM pattern with Unity Engine as front end [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I plan to make some applications that will let me organize tasks from home or from somewhere else. For this I need a database server (a virtual one running at home), a backend part (the business logic) and the front end (the view). At school we learned the MVVM via WPF, but to be frank I use it only when it is explicitely required.
There are a lot of benefits in favour of Unity like
Artist friendly
Can compile to mobile, web and desktop
Fast development (in my case at least)
Has a lot of built in features I can harness.
Now, even as simple as I will make an app like this, sometimes I might want to extend it, improve it or change some components entirely.
I know how to use MVVM in WPF but I only have some vague ideas for the Unity implementation which I would like someone skilled to overview.
The front end (Unity) would take care of sound management, fancy animations and the UI itself. But UI button events cannot access directly the database, so I thought of building some bridge classes. Say I want to delete a reminder, as an easy example. In an OnButtonClicked() method I would just call a BridgeClass's PleaseDeleteThis(MyReminder) and inside that method there's the backend solution that actually finds that reminder by id and removes from the database, then sends an everything all right flag back to the front end app so I know it was successful.
What I thought of is that using these bridge classes I wouldn't have to worry about what happens if I change the database server or the front end, as all they have to know is communicating with the bridge. I know the example was over simplified, but how doable would this one be regarding the component integrity and the MVVM pattern?

MVVM has been successfully used by AAA software houses to build games. The makers of Shipbreakers (aka Homeworld: Deserts of Kharak) wrote their code such that the View was a MonoBehavor I believe, VM and M were POCO classes written external to and independent to Unity so as to speed development. They can have their own Views for prototyping external to Unity.
They also wrote their own debugging visualisers and property editors for Unity.
https://www.youtube.com/watch?v=q9aeNtKKXeo
MVVM is about at the 19:18 mark though I do recommend to watch the whole thing as there are some other great things in there.

Basic Code Restructure Query [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
So, before I post my question, I will add a little bit of premise to it. I have written quite some code for academic purposes, but never before was it for production or an actual client.
What I would always do is this:
private void button1_Click(object sender, EventArgs e)
{
//Do all the programming here
}
However, now when I have to build actual software for client (a small one), I find this process tedious and hard to handle as the code grows long.
I still create separate classes and do some of the work here and there, but I think it's not the correct direction.
What am I missing? How professional developers do it?
Thanks.
EDIT : This is not exactly a coding question however I still choose StackOverflow because I really want the different perspectives of the superb professionals present here. I am just an industry newbie, so I really need to start learning in the right direction.

I find this process tedious and hard to handle as the code grows long.
You are correct.
I still create separate classes and do some of the work here and there, but I think it's not the correct direction.
It is the correct direction. Programming is about abstraction. Properties, methods, handlers, classes, and so on, are all abstractions. Abstractions are useful because they present less complexity than their implementation details, and can therefore be understood and used effectively. Just as you do not learn how to drive by manipulating valves and cylinders and springs and camshafts; you learn abstractions like brakes and gear selectors.
When you learn to drive you are handed a pile of abstractions which you must learn to use. When you are programming you are both handed a pile of existing abstractions -- variables, lists, types, and so on, are all abstractions -- but you are also expected to build your own.
How do professional developers do it?
This is not a site to teach you how to program. This is a site for specific questions about actual code. Professional developers do it by spending thousands of hours learning from others and practicing their craft; go get started! Come on back when you have a specific question about actual code.

I think you are doing it right ! Indeed managing large programs is a hard job, you have to know how to modulate your code. You can create diagram representing your project so it will make the editing a lot easier.
Here is a link with some tools for Architecture and Modeling with Visual Studio
https://www.youtube.com/watch?v=ThEP7DgVAC0

Code First or Model First [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm about to develop some LOB applications using VS2012, WPF, Sql Server Express 2012, Unity, Prism.
I don't have legacy applications to care about.
Is it ok if I choose the Model First workflow for my upcoming projects, are there some important benefits in the Code First workflow that I would not be receiving?
If there's any that I could not overlook, then could I start with Model First and then switch to Code First?, it happens that I'm more confortable designing databases with the designer than by code, this is the main reason for this question.

If you're more comfortable working with databases first, I would go down that route. This question has a lot of pros/cons for each.
I've recently used code first for a project and I regret that decision. Although it is incredibly powerful, it was an unnecessary learning curve and ultimately took far too long to setup a simple schema.
If you want to learn how code first works, and time isn't an issue, then you may as well go for it. Else, what do you really have to gain from it?
Ultimately though, if you're developing it and you already have a sufficient skill set in one of these, use it.

I have created WPF applications using code first and MVVM patterns + DI (though not Prism).
It took a while to convince me to move away from the edmx models, but I've found Code First to be a much cleaner approach, with no apparent downsides.
I think you could easily move to model first from code first, though you probably wont need to. I haven't tried it - you might need automapper.
I have successfully taken existing dbs and moved over to CF though it is a bit messier.

What is new since Family.Show? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am relatively new to WPF and have been looking at Family.Show. It looks like a great reference application, but it has not been updated since February 2009. When I am looking through this code, are there any outdated techniques in here or improvements in the platform that I should be aware of?
[Edit] I have gotten a number of responses about PRISM and MVVM. I can now see how this question was not clear. Family.Show is one of the few WPF applications that I think really looks like a nice WPF application. I would like to use it as a model, but am concerned that the XAML and controls that they use might have been replaced with newer elements. Would someone give me some guidance in this respect?
[Edit] I should mention that I have read WPF 4 almost in its entirety, but not having much experience actually writing WPF applications, it is not easy for me to spot old or outdated technologies in something like Family.Show.

On the WPF side of things, not much has changed since 2009.
There are still DataTemplates, Styles, Data binding etc. They are used just like they have been used back then.
In the current version of the .NET framework a few more controls are present out of the box, so you might find some user controls in that example that are no longer necessary. However, the existing controls haven't changed as far as I know.
However, that application doesn't make any use of MVVM, which I personally find a big drawback.
So, you can use the application as a means to study WPF, but you shouldn't adept its architecture style in your own applications.

I think Prism is a very good framework to build enterprise(bigger) applications but at first sight it could be a little difficult. If you are new to WPF but want to get to know the WPF and MVVM better, check http://caliburnmicro.codeplex.com/ or http://waf.codeplex.com/. (With them it is a little easer to understand the principles.) You can get the source too and it is a good documentation to both, so you can learn a lot.
I think it is important to be familiar with the MVVM principles as a WPF developer.
I can suggest to you to watch the following two video from MIX conferences too:
http://channel9.msdn.com/events/MIX/MIX10/EX14
http://channel9.msdn.com/events/MIX/MIX11/OPN03

I would have a look at prism - its a great way to build WPF apps.