XAML or C # code

Question

I do not like to use XAML. I prefer to code everything in C #, but I think I'm doing something wrong.

When is it better to use XAML and when do you use C #? What is your experience?

Answer 1

Creating an entire window in C # can be useless for code. The best part about WPF is that XAML allows you to separate your design from your logic, making code much easier to read.

I will use C # when I need to create dynamic controls, but I usually keep my overall design, static storyboards, styles, datatemplates, etc. in xaml.

Answer 2

Tag this video on MVVM in WPF. If you want to wrap your head around how to organize a WPF application compared to what happens in XAML, behind code and other abstractions, this is a great place to start.

Answer 3

You can go too far with XAML. Those who want all of its user interface (including logic, event handling relationships, etc.) defined in XAML probably lacked a point.

The goal of XAML is to provide a common format for determining how things should look. It should be just a description of how to lay things, how their color and style visually.

There is very little point in trying to use it as a replacement for other aspects of C #, since C # has a constant start in terms of programming functions — reuse (defining types and functions), referring to variables, procedural programming, and even declarative or functional styles.

Personally, I really like to flush the user interface with a Linq expression!

The ultimate absurdity was achieved using the pattern that I saw when they used workflow actions as children of a button to deliver a Click handler, so the whole program was in XAML. It sounds cool, but the problem is that it was significantly uglier and unreadable than the equivalent C # or VB.NET program, and so anything ready for use in C # should be replaced with a more detailed one, flaky equivalent. Nothing was actually obtained by this translation into a uglier syntax - this is the same program only more disgusting. XML is a poor basis for the syntax of a common programming language. Start by writing a larger character as > !

In a parallel universe, Microsoft released C # 3.0 before it finished XAML. The XAML team adopted the C # 3.0 object / list initializer syntax instead of XML as its syntax. And all this debate never happened.

Answer 4

My experience is that some things run much faster in C #, while most of them run faster in XAML. When it takes 5 lines of C # code to execute one line of XAML code, it is very easy for me to choose which is better.

Answer 5

Basically, XAML is for expressing visual design, C # is for expressing logic.

Any visual construction must be performed in XAML, any logic must be implemented in C #.

- This allows the designer to visualize the design without worrying about changes in the logic and even replacing the entire visual design at runtime using free-XAML.

“It also means that you could replace either logic or visual design without a hack.”

- The connection between them must be done with data bindings and with command bindings.

Practice I use:

1. Define a model (model of a business data object) in a separate C # code.

2. Define the constant parts of the view (the constant parts of the graphical user interface, for example, windows, menus, ...) in XAML (it is advisable to use Blend, not VS for this).
* Do not define the style (colors, fonts, ...) here.
* Do not write event handlers for buttons (in most cases) in code-behind-the-XAML, use command bindings instead.

3. Determine how the model is represented in the view (graphical interface for viewing / editing data objects) using the XAML "ResourceDictionary" located in separate files.

- Record using blend, and then add XAML bindings using VS (adding Resharper for Jetbrains for VS will help with the binding expression).

- If the types of objects are not known during development, you can use "free-XAML" and put XAML in a folder in which files can be added / edited internally without recompilation.

4. Create a connection between the model and the view (controller / view model) in C #, which:
* Creates views as needed (for dynamics objects)
* Data-binds the view to the model (sets the DataSource view as the corresponding object in the model)
* Executes commands
* Command-binds the view to the implementation of teams within itself

5. In Application.xaml, remove StartupUri = "MainWindow.xaml" and add Startup = "ApplicaitonStartUp".
In the ApplicationStartUp () event handler:
* Download any free XAML that you have
* Create a controller
* Create main window
* Create model
* Connect the controller to the model and the main window
* Show main window
* (Save the model, controller, and main window to private fields here to make sure they are all saved)

6. Add the style (colors, fonts) to a separate XAML file in the ResourceDictionary (using the mixture for this, or buy a ready-made theme / XAML file).

Answer 6

The desire to write your user interfaces in C # instead of XAML is just a manifestation of how comfortable you are in XAML.

For me, my personal goal is to write as little code as possible. Simply put, the code behind is hard to test, but can (and usually does) include logic that fails testing. XAML is declarative (e.g. HTML) and does not contain any logic, so there is nothing to test unit-test. I save my view code in XAML and I save my view logic in my ViewModel (MVVM), which is VERY easy to test.

As soon as you become more comfortable with XAML, the more you will understand its advantages over the representation design in procedural code ... Using a template like MVVM, you take one more step and realize that the code code is useful only in rare cases.

Answer 7

The most important thing to keep in mind is that XAML is for presentation. Your entire presentation should be in XAML. If you have logic, you save this from your XAML - in your C #.

Imagine replacing your XAML file with LOOKS being completely different, but still using the same data as in the split case.

Answer 8

One of the nice things about XAML is the separation of the presentation of logic. This division is not only theoretical, but also practical. In my case, most of my user interfaces are now handled by the designer. This designer uses the mixture and does not know C #, is not interested in learning C #, and frankly, this is not necessary. This designer is a real designer, an artist who knows how to use these tools so that everything looks really very beautiful. Basically, my philosophy is that the more I use XAML, the less work I have to do in the user interface, because it can do it. It worked well for us. I usually create my control to be carefree, give them a simple, no-frills look, use a DataContext to bind my object (btw DataTriggers is a great way to cut code). As a result, I will often check my code, return the next day, synchronize it, and the user interface will look completely different, but it still works !!!

Of course, it took at least 1/2 a year, but now this model seems to work, and our user interface looks like Kick A ##, our application is commendable, and I work a little on the user interface and get to work on more cool things. In short, I think the code behind may be a little more developer-oriented and forget about another group that can benefit, outperform and make a living with WPF, namely designers.

Of course, there are still moments when it is required that XAML / WPF sing and dance, and once we need to train designers in the right way to do something, but I think that its value for investment pays off many times in large projects (maybe not so short one0

Answer 9

XAML, MXML all these things work as long as you develop a simple interface with some medium complexity. Once your user interface is complex and rich, automatic data bindings will cause more problems than their benefits. The goal of XAML is not to simplify programming, it is to separate the user interface from the logic so that the UI tool is easy.

No data bindings, no event handlers .. suppose you never see your XAML again and write code.

XAML is a presentation. Data binding is not a representation. his presentation logic. put all the presentation logic in the code behind (data binding and handlers). Developers have their own code, designers own XAML. if you are a developer, and if you are dealing with XAML, then move this part to code.

we can write WPF applications without XAML too.

Thanks Vinoth Kumar R (Enough using Flex MXML data binding)

Answer 10

It is not only about you, but also about your team, some of which may be designers.

Answer 11

XAML and C # are a really good way to separate logic from design, as already described.

For a typical programmer, the way of programming really changes using WPF, assuming that the programmer comes from the background of C ++, VB, WinForms, ATL and MFC, the background of which was not as natural as the logical interface from the logic as with XAML and C #.

It takes some time to get used to this method of programming, but more and more experience is becoming really effective.

Before you begin, it’s very useful to study the MVVM template and run the tutorials to understand the power of the template, as well as its benefits.

WPF and C # applications based on the benefits of MVVM templates:

1. User experiment and usability. Separating the logic from the user interface, it becomes more natural to create a specialized designer working on the design and animation of the user interface. In this way, the programmer can focus on logic and technical solutions, while the user interface is designed by someone who knows the design. This has been a problem for many software companies, at least in the industry, who are actually programmers who are also developing the interface, and this has led to a lot of support, support, and effective use.

There is a higher likelihood that it will turn out to be in more user-friendly applications if you have a character with a usability-oriented background of use, not a technical solution. There is a really interesting book about these examples, "User Interface Design for Programmers" by Joel Spolsky.

Using the MVVM template for a XAML application, there is a good chance that we will see more applications for the user.

2. Maintanence Maintenance that is expensive in software development. He may feel that the MVVM pattern is a lot of overhead at the beginning, but while features are added, a more complex and advanced application becomes more useful. You will find that it is really easy to support such an application. For a review you can watch this video:

3. Blending competencies A dedicated designer and a special programmer working in a team to achieve the best result is a very good way to mix competencies. Instead of hiring programmers, organizations need to combine competencies to ensure the best results.

4. An opportunity for the design of interested programmers. Finally, fancy applications can be implemented in the Windows environment. If you are a programmer who is interested in design, Microsoft Expression Blend really opens up the possibilities for exploring and achieving attractive and useful applications with a nice design.

You can use the risk using XAML and C #, MVVM or not, the great features and flexibility that it provides can also be a drawback. Giving the programmer freedom in this new easy user environment, applications can have a wide range of animations, colors, everything that this new environment provides. Recall how you added user interface controls in C ++ and ATL envrionment.

However, the benefits are greater, and I hope you get inspired to use XAML instead of C # for the user interface when you get used to it. I am sure you will like it.

Link to a good tutorial: MVVM XAML C # Tutorial

Answer 12

I originally came from web development and studied WPF / Silverlight at the moment. For me, the XAML model makes much more sense to me than WinForms. I view XAML as if it were HTML and .cs files, like code.

Answer 13

I like clean code, the less code I have, the cleaner it is. Code can be written in millions of ways, XAML is more restrictive. XAML can shorten code when necessary, of course. If I can put something in XAML, I will do it. Tools can read XAML and do things with it. Much less with code. XAML processing tools and infrastructure will evolve and improve, making more and better work with existing XAML. Can't say that about code. The more XAML evolves, the more we can declaratively define our applications.

For me, using XAML is like using LINQ. If I can write a one-line expression that is easy to read, and let the structure decide the best way to implement what I want, I feel good. I definitely try, as far as I can, to use declarations of what I want instead of hardcoding, as I want it to be done. F # is another good example of this paradigm.

Answer 14

All logic should be in the code, regardless of what programming language you use in computer programming. XAML should never replace this even in the ControlTemplate, although this is good, but it is much easier to unit test and debug the code.

Answer 15

It seems that none of the answers mentioned an important point: https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465340.aspx

XAML is just procedural code (just easier)

 <Grid x:Name="ContentPanel" Margin="12,0,12,0"> <Button Height="72" Width="160" Content="Click Me" /> </Grid> 

"The following shows how this XAML can be partially replaced by code written in C # or Visual Basic."

 // Initialize the button Button myButton = new Button(); // Set its properties myButton.Width = 160; myButton.Height = 72; myButton.Content = "Click Me"; // Attach it to the visual tree, specifically as a child of // a Grid object (named 'ContentPanel') that already exists. In other words, position // the button in the UI. ContentPanel.Children.Add(myButton); 

If you work with Windows forms, for example, you probably remember that the window designer generates a .designer.cs file containing code similar to the example from the link above. Such declarative code is much better represented in XAML than C #.

For any application other than toys, you ALWAYS prefer XAML to define an interface and connect it to logic using MVVM.

Answer 16

Some things are easier to maintain or debug code.

Answer 17

It should not be mentioned that you can do more in Xaml2009, which should now be done in code.

Not surprisingly, BAML will not fully support xaml 2009 in 2010, so you won’t be able to compile xaml in 2010. And you have to wait for a later version of blend to complete the full dev development cycle. (later 3)

Douglas

Answer 18

XAML can be thought of as a combination of XHTML and CSS, or XML and XSL, which are used for structure and design. Any form of logic should be in C #. Thus, structure and design are separated from logic. Your code should be cleaner using this approach. Another positive thing is that tasks can be easier to share between designers and programmers.

One more thing ... this is the XAML definition from MSDN:

Extensible Application Markup Language (XAML) is a markup language for declarative application programming. Windows Presentation Foundation (WPF) implements the Extensible Application Markup Language (XAML) loader and provides Extensible Application Markup Language (XAML) language support for Windows Presentation Foundation (WPF) types, so you can create most of your application user interface in extensible application markup Language (XAML). In addition, the SDK includes an extensible application markup language (XAML) editing tool called XAMLPad. You can use this tool to experiment with the Extensible Application Markup Language (XAML) in real time.

Link to a quote.

Answer 19

Free-style WPF programming in C # helps reduce code size and complexity. See this answer for an example of using free style with WPF.