Showing posts with label Visual Studio 2013. Show all posts
Showing posts with label Visual Studio 2013. Show all posts

Wednesday, January 15, 2014

Interface level validations of DataObjects

Purpose

I was recently working on a project where I wanted to create the most granular interfaces possible and then group them into usable objects. My intent was to pass these objects around to shared utilities and services that would focus on the interfaces and thus be reusable by intent instead of specific implementation. For example, we would create an interface each for phone number, email and street address. These interfaces could be used on a customer, vendor, or employee object to ensure a standard implementation of the fields. Then, we could build our communications services to work off the interfaces for communication types and thus be generic to the entity being contacted. By doing this, I would be able to build singularly focused services that dealt with small tasks on data objects with a disregard for their specific implementation beyond the interface.

Validation

Being a big fan of data contracts with ability to run self-aware validations(e.g. validations that can only consider the scope of the contract itself without any relationships), I found myself needing a way to have all objects validate based on the requirements of the smaller interfaces, within the CRUD services of the manifested object. I also wanted to ensure the ability to dynamically add validation routines and have them picked up by the calling services without having to couple them together.

Solution

By creating a custom attribute and applying it to methods in the interface, I would be able to reflect through the methods of any object and trigger it to self validate using any and all methods that were added to the object from the implemented interfaces. Next, we simply call a data contract extension method that to invoke all validations. Here are the examples.
Custom Method Atribute

[AttributeUsage(AttributeTargets.Method, Inherited = false)]
public class InterfaceValidation : Attribute
{
    //...
}
Data Contract Extension

public static class DataContractExtensions
{
    public static T CallInterfaceValidations<T>(this T obj)
    {
        var methods = obj.GetType().GetMethods();
        object[] parameters = null;
        foreach (var method in methods)
        {
            var attributes = method.GetCustomAttributes(typeof(InterfaceValidation), true);
            if (attributes != null && attributes.Length > 0)
            {
                try
                {
                    method.Invoke(obj, parameters);
                }
                catch (Exception)
                {

                    throw;
                }

            }
        }
        return obj;
    }
}
Assign the attribute to a method

[InterfaceValidation]
void ValidateSomething();




Monday, November 18, 2013

Team Foundation Services is now Visual Studio Online

Microsoft officially launched Visual Studio Online (Formerly Team Foundation Services) last week.  The announcement came with news of many added features and benefits.  Here is an overview of the announcement:

Pricing

The good news is that if you have MSDN, you are most likely going to still not be charged for day-to-day usage. The bad news is that if you have product owner or product manager roles our your team and want them to use VSO for backlog interaction, etc.  They will now need to pay a membership fee.  The MSDN license that allows that access free, is the Ultimate level, which is the most expensive MSDN package there is.   This is going to cost at least $45 monthly for these employees (of course depending upon their role in your organization).  You can find the breakdown of pricing levels here.  The other financial consideration is that you will be charged for build time on any build and deploy jobs.  This is basically going to cost a couple of pennies per minute every time you do a CI style build. I did some investigation and found out that this does include publish time. In our world, that is roughly 65% of the time the build job is running.  So, you will pay the going rate while your build is being uploaded and deployed to the Azure instances for which you are already paying.

Link VSO with Azure

Link your VSO account to your Azure account and have a single portal for managing them both.  Very handy.  Details here.

Monaco

Monaco is a new development service specifically designed for building and maintaining Windows Azure Websites. With Monaco, developers have a lightweight free companion to the Visual Studio desktop IDE that is accessible from any device on any platform. Monaco is a rich, browser based, code focused development environment optimized for the Windows Azure platform, making it easy to start building and maintaining applications for the cloud.  Here are some cool videos on Channel9

Application Insights


With this “360 degree view” of your application, Application Insights can quickly detect availability and performance problems, alert you, pinpoint their root cause and connect you to rich diagnostic experiences in Visual Studio for diagnosis and repair. It also supports continuous, data-driven improvement of an application. For example it highlights which features are most and least used, where users get “stuck” in an application, where and why exceptions are occurring, which client platforms are being used with which OS versions, and where performance optimizations will make the biggest impact on compute costs.  You can sign up for the free preview here.  Following are some sample screen shots:


Dashboard
Visual Studio Integration

Environment Metrics

Friday, October 18, 2013

ASP.NET Identity for 4.5

ASP.NET membership has gone through many changes over the years. From simple membership to SQLProviders to OWIN, the needs of developers are constantly changing. .Net 4.5 has brought another change to the identity model. We have to let go of the assumption that users will log in by entering unique credentials to our application. Increasingly, users expect to leverage a single online identity to drive all of their web-based experiences (e.g. Facebook, Twitter, etc.) Developers should also want users to be able to log in with these social identities so that our applications can provide a rich and integrated experience to the users' online life.

Unit testing code should be a core concern for application developers. MVC is a great pattern and platform for those who want to unit test their code.  Now, you should easily be able to do that with the membership system. ASP.NET Identity was developed with the following goals (Verbatim from Microsoft):
  • One ASP.NET Identity system 
    • ASP.NET Identity can be used with all of the ASP.NET frameworks, such as ASP.NET MVC, Web Forms, Web Pages, Web API, and SignalR. 
    • ASP.NET Identity can be used when you are building web, phone, store, or hybrid applications.
  •  Ease of plugging in profile data about the user 
    • You have control over the schema of user and profile information. For example, you can easily enable the system to store birth dates entered by users when they register an account in your application. 
  •  Persistence control 
    • By default, the ASP.NET Identity system stores all the user information in a database. ASP.NET Identity uses Entity Framework Code First to implement all of its persistence mechanism. 
    • Since you control the database schema, common tasks such as changing table names or changing the data type of primary keys is simple to do. 
    • It's easy to plug in different storage mechanisms such as SharePoint, Windows Azure Storage Table Service, NoSQL databases, etc., without having to throw System.NotImplementedExceptions exceptions. 
  • Unit testability 
    • ASP.NET Identity makes the web application more unit testable. You can write unit tests for the parts of your application that use ASP.NET Identity. 
  • Role provider 
    •  There is a role provider which lets you restrict access to parts of your application by roles. You can easily create roles such as “Admin” and add users to roles. 
  • Claims Based 
    • ASP.NET Identity supports claims-based authentication, where the user’s identity is represented as a set of claims. Claims allow developers to be a lot more expressive in describing a user’s identity than roles allow. Whereas role membership is just a boolean (member or non-member), a claim can include rich information about the user’s identity and membership. 
  • Social Login Providers 
    • You can easily add social log-ins such as Microsoft Account, Facebook, Twitter, Google, and others to your application, and store the user-specific data in your application. 
  •  Windows Azure Active Directory 
    • You can also add log-in functionality using Windows Azure Active Directory, and store the user-specific data in your application. For more information, see Organizational Accounts in Creating ASP.NET Web Projects in Visual Studio 2013 
  • OWIN Integration 
    • ASP.NET authentication is now based on OWIN middleware that can be used on any OWIN-based host. ASP.NET Identity does not have any dependency on System.Web. It is a fully compliant OWIN framework and can be used in any OWIN hosted application.
    • ASP.NET Identity uses OWIN Authentication for log-in/log-out of users in the web site. This means that instead of using FormsAuthentication to generate the cookie, the application uses OWIN CookieAuthentication to do that. 
  • NuGet package 
    • ASP.NET Identity is redistributed as a NuGet package which is installed in the ASP.NET MVC, Web Forms and Web API templates that ship with Visual Studio 2013. You can download this NuGet package from the NuGet gallery. 
    • Releasing ASP.NET Identity as a NuGet package makes it easier for the ASP.NET team to iterate on new features and bug fixes, and deliver these to developers in an agile manner.

Friday, August 2, 2013

OWIN and the Katana Project

OWIN

OWIN (a.k.a. Open Web Interface for .NET) is a new way of processing HTTP requests in .NET.  It is a specification describing how .NET web servers and .NET applications should interface and interact. The idea is that by decoupling the server and application we are able to write code independent of the host platform.  Our code at that point can be host agnostic and allow us much more flexibility on our chosen publishing environment.

IIS currently does double duty by handling both the host and server responsibilities.  To be clear, by host duties, I mean the process management, and by server, I mean network management and request handling.  This means that we as developers have to use packages specific to IIS suck as HttpModules, HttpHandlers, etc.  While this is effective, it makes our application tightly coupled to a specific hosting environment.  So, if we would want to target something a little more small to host a WebAPI, we would be out of luck.  OWIN gives us the ability to decouple those two things which gives us the flexibility to choose components based on individual functions while selecting only the ones we need and substituting only the ones that are actually different across hosting platforms. All of those changes would actually take place beneath the application.  Hm.. where have I seen this kind of thing before?

The way I understand it, a server in OWN is made up of an environment dictionary, of the form IDictionary<string, object>, used for holding the request processing state: things like the request path, the headers collection, the request bits themselves, and a delegate, of the form Func<IDictionary<string, object>, Task>, which is used to model how the components appear to each other.  This means that an app is a list of those components executed in sequence, each of those awaiting the next and passing the environment dictionary to each other.  This seems very dynamic and portable, which is a really strong position for a WebAPI or other hosted service. 

Katana Project

Katana is a set of components by Microsoft for building and hosting OWIN-based web applications.  Katana has host, server, and middleware source code and documentation located here. These tools are available via NuGet.  These products are actively developed by the Katana team assigned to the Microsoft Open Tech Hub and in collaboration with a community of open source developers.