In any application, you want to keep the coupling between any two or more objects as loose as possible. Coupling happens when one class contains a property that is used in another class or uses another class in one of its methods. If you have this situation, then this is called strong or tight coupling. One popular design pattern to help with keeping objects loosely coupled is called the mediator design pattern. The basics of this pattern are very simple; avoid one object directly talking to another object, and instead use another class to mediate between the two. This class is called a message broker. The purpose of this blog post is show you a simple approach to using a message broker in your XAML applications.
I challenge you. I challenge you to think of a report that doesn’t rely on a date somewhere in it. Thought of one? If you did, is the information in the report actually valuable without some type of date range boundary? Even in academia and clinical research, where groundbreaking reports are published and stand up to scrutiny for decades, researchers still clearly call out the dates in which the data was collected. They do this because they know the results of their experiments were valid for the date and time they were collected, but could still change at any time. Remember: it was a scientifically held belief that the Earth was the center of the universe for a long time.
When I started out as a wee programmer back in the 1980s, “Hungarian Notation” was all the rage. Invented by Charles Simonyi (a Hungarian guy!), it espoused a naming convention for variables that included the intent (or kind, or type) for that variable. Unfortunately, the semantic meaning of type is overloaded, and many developers assumed it meant “data type.” So, you had variables that were clearly string variables called strFirstName or clearly integer variables called intCount. In a type-safe compiled language, this is redundant, but many Microsoft devs, myself included, blindly followed the pattern because we learned it, and it made sense on the surface.
So far in this blog post series on uploading files with MVC, you have learned how to style the file upload control, use a view model for data binding, and create a thumbnail from an uploaded image. In this post, you learn to store the uploaded file in a folder on your server.
Whether you are building a new mobile app for your business or want to improve your mobile website, having a mobile strategy in place is essential. After all, by 2020, there will be roughly six billion mobile users. A good strategy will create a memorable mobile experience for your customers and support your business’s goals at the same time.
In the last two blog posts in this series, you learned to style the file upload control and to use a view model to simplify data binding. In this third blog post, you build a class that allows you to take a large image and create a thumbnail image from it (See Figure 1).
In my last blog entry, I discussed why you need a solid demand management process. Demand is what others are asking you to do. It is your “to-do” list or backlog of activities. From this list or backlog, you must be able to select the right work. The other part of what you do for a living is executing the work: doing work right. Therefore, “right work” (what is best to do next) vs. “work right” (what people, processes, or tools will be employed to do the work in the most effective way).
In the last blog post, you learned to style the file upload control and to upload a file. You gathered information about the file and placed that information into individual variables in a controller class. In this blog post, you will create a view model class with properties to hold the file information, and a method to extract the file information and upload the file.
There are many reasons your company might be considering moving your operations to the cloud. Perhaps you have an aging mainframe that is costly to maintain and repair, or you are having a hard time finding skilled people to service it. Maybe your IT team is spending more time and money upgrading hardware than innovating. Or, it could be that you are not considering a move to the cloud but are curious about its pros and cons. In this blog post, we will address common concerns about moving to the cloud so that you can carefully consider your options and make the right decision for your business.