System.Transactions.TransactionScope provides an implicit programming model in which the transactions are automatically managed by the infrastructure. It provides a simple mechanism for you to specify a code block to participate in a transaction. TransactionScope reduces the complexity of code that need to use transactions and it allows existing transaction providers to be retrofitted to participate in this programming model. Nested transaction work transparently. Disparate transaction providers can participate in a transaction without increasing the complexity of your code. No wonder TransactionScope is so popular! Read More…
- Your code is easier to understand, maintain and troubleshoot.
- You are much more productive when you leverage the frameworks’ (WPF, Silverlight, XAML, WinRT) built-in features like Data Binding, Resource Dictionaries, Dependency Properties, Routed Events, Commands, etc.
- You can test your app’s behavior “under-the-skin,” avoiding the pitfalls and cost of testing at the UI level.
- Your ViewModels afford testability. You can have unit test coverage allowing “Test-Driven-Development” and “Automated Regressions.”
- Decoupling the View from the ViewModel in the way enabled by MVVM allows designers and developers to work productively in harmony.
As noted in the previous post, the System.TimeZoneInfo uses AdjustmentRules to account for DST Transitions, and the default AdjustmentRules do not incorporate all the available DST data. But it is possible to create a custom TimeZoneInfo and populate the AdjustmentRules with DST Transition data available to cover all DST transitions.
However, as I learned more about how Bootstrap grid is used, I realized that there is a problem with the way I was using Bootstrap. Bootstrap’s grid is steering me away from the path of semantic markup.
Upon startup, the app retrieves the population counts for each U.S. State and displays those counts in a marker positioned in the geographic middle of each state.