Tugberk's Blog

Getting Started With OWIN and the Katana Stack

Sat, 04 May 2013 21:04:00 Z

As usual, I tweeted about my excitement which finally led me to this blog post:

It was amazing to be able to pull assemblies through NuGet w/o being tied to GAC. Now it's super awesome to do the same for web servers #win
— Tugberk Ugurlu (@tourismgeek) May 4, 2013

OWIN and Katana project is the effort moving towards that direction and even through it's at its early stages, the adoption is promising. Katana is a flexible set of components for building and hosting OWIN-based web applications. This is the definition that I pulled from its Codeplex site. The stack includes several so-called OWIN middlewares, server and host implementations which work with OWIN-based web applications. You can literally get your application going within no time without needing any installations on the machine other than .NET itself. The other benefit is that your application is not tied to one web server; you can choose any of the web server and host implementations at any time without needing to recompile your project's code.

To get started with Katana today, the best way is to jump to your Visual Studio and navigate to Tools > Library Package Manager > Package Manager Settings. From there, navigate to Package Sources and add the following sources:

MyGet Katana: http://myget.org/F/katana/
MyGet Owin: http://myget.org/F/owin/

Now, we should be able to see those sources through PMC (Package Manager Console):

We performed these actions because latest bits of the Katana and OWIN Hosting project are pushed to MyGet and those packages are what you want to work with for now. As you can guess, those packages are not stable and not meant to be for production use but good for demonstration cases :) Let's start writing some code and see the beauty.

I started by creating an empty C# Class Library project. Before moving forward, I would like to take a step back and see what packages I have. I selected the MyGet Owin as the current package source and executed the following command: Get-Package -ListAvailable -pre

These packages are coming from the OWIN Hosting project and I encourage you to check the source code out. Let's do the same for the MyGet Katana source:

We got more packages this time and these packages are coming from the Katana project which is hosted on Codeplex. These packages consist of OWIN middlewares, host and server implementations which we will have a chance to use some of them now.

Let's start installing a host implementation: Microsoft.Owin.Host.HttpListener pre-release package. Now, change the current package source selection to MyGet OWIN and install Owin.Extensions package to be able to get the necessary bits and pieces to complete our demo.

The Owin.Extensions package will bring down another package named Owin and that Owin package is the only necessary package to have actually. The others are just there to help us but as you can understand, there is no assembly hell involved when working with OWIN. In fact, the Owin.dll only contains one interface which is IAppBuilder. You may wonder how this thing even works then. The answer is simple actually: by convention and discoverability on pure .NET types. To get a more in depth answer on that question, check out Louis DeJardin's awesome talk on OWIN.

What we need to do now is have a class called Startup and that class will have a method called Configuration which takes an IAppBuilder implementation as a parameter.

public partial class Startup {

    public void Configuration(IAppBuilder app) {

        app.UseHandler(async (request, response) => {

            response.ContentType = "text/html";
            await response.WriteAsync("OWIN Hello World!!");
        });
    }
}

For the demonstration purposes, I used the UseHandler extension method to handle the requests and return the responses. In our case above, all paths will return the same response which is kind of silly but OK for demonstration purposes. To run this application, we need to some sort of a glue which needs to tie our Startup class with the host implementation that we have brought down: Microsoft.Owin.Host.HttpListener. That glue is the OwinHost.exe which we can install from the MyGet Katana NuGet feed.

OwinHost.exe is going to prepare the settings to host the application and give them to the hosting implementation. Then, it will get out of the way. To make it run, execute the OwinHost.exe without any arguments under the root of your project and you should see screen as below:

We got this unfriendly error message because the OwinHost.exe was unable to locate our assemblies as it looks under the bin directory but our project outputs the compiled assemblies under bin\Debug or bin\Release; depending on the configuration. Change the output directory to bin through the Properties menu, rebuild the solution and run the OwinHost.exe again. This time there should be no error and if we navigate to localhost:5000 (as 5000 is the default port), we should see that the response that we have prepared:

Cool! You may wonder how it knows to which host implementation to use. The default behavior is the auto-detect but we can explicitly specify the server type as well (however, it's kind of confusing how to do it today):

OwinHost.exe is great but as you can guess, it's not our only option. Thanks to Katana project, we can easily host our application on our own process. This option is particularly useful if you would like to deploy your application as a Windows Service or host your application on Windows Azure Worker Role. To demonstrate this option, I created a console application and referenced our assembly. Then, I installed Microsoft.Owin.Hosting package to be able to host it easily. Here is the code to do that:

class Program {

    static void Main(string[] args) {

        using (IDisposable server = WebApp.Start<Startup>()) {

            Console.WriteLine("Started...");
            Console.ReadKey();
        }
    }
}

When I run the console application now, I can navigate to localhost:5000 again and see my response:

I plan on writing a few more posts on OWIN-based applications but for now, that's all I can give away :) The code I demoed here is available on GitHub as well: https://github.com/tugberkugurlu/OwinSamples/tree/master/HelloWorldOwin. but run the Build.cmd file before starting.

Note: Earlier today, I was planning to play with ASP.NET Web API's official OWIN host implementation (which will come out in vNext) and writing a blog post on that. The playing part went well but Flip W. was again a Sergeant Buzzkill :s

@tourismgeek writing a post now
— Filip W (@filip_woj) May 4, 2013

References

Katana Project
Official OWIN Hosting Project which includes OWIN hosting components
OWIN - Run your C# for the web anywhere by Louis DeJardin
OWIN – compile once and run on any server (kind of an old but still very useful blog post by Louis DeJardin)

Cleaning up With PowerShell After Removing a Windows Azure Virtual Machine

Sun, 28 Apr 2013 17:10:00 Z

When you remove a Windows Azure virtual machine, you are not actually removing everything. I hear you saying "What!!!"? Let's dive in then

As each VM is kept under a cloud service, that cloud service one of those things that remain after you remove your VM. Other thing is the disk (or disks, depends on your case) which is attached to your VM. If you didn't attach any data disks, at least your OS disk will remain inside your storage account even if you remove your VM. However, you cannot go and directly delete that VHD file just like a typical blob because there is a lease on that blob as it's still viewed as one of your registered disks.

Let's look at a case of mine on removing a Windows Azure VM. Yesterday, I created two VMs for demonstration purposes on a presentation and after the presentation, I removed those VMs by running "Remove-AzureVM" PowerShell command. So far, so good. When I go to the portal, I don't see those VMs as expected and I don't see any cloud services.

If you create a VM, the new portal is not showing that you have a cloud service but it implicitly creates one for you under the covers. As soon as you attach another VM to that cloud service, the cloud service shows up on the new portal as well. In either of these cases, the generated cloud service is completely visible to you through the REST management API. So, you can view them through PowerShell Cmdlets.

Let's run "Get-AzureService" PowerShell command to see my cloud services:

These are the generated cloud services which belong to my removed VMs. As far as I know, these cloud services won't cost me anything as they contain no deployments but it would be nice to remove them as I don't need them.

I got rid of the unnecessary cloud services. The next and final step of this cleaning is to remove the OS disks I have. This's actually more important because disk VHD files are stored inside the Windows Azure storage as blobs and each OS disk is approx. 127GB in size. So, I will pay for them as long as I keep them. Through new Windows Azure Storage PowerShell Cmdlets, I can view my VHD container to see which VHD files I have:

As you can see, I have two unnecessary VHD files which remained after my VM removal. At this stage, you might think directly deleting these blobs but as mentioned before, it will fail if we try to do that.

The error message I got is very descriptive actually: There is currently a lease on the blob and no lease ID was specified in the request. Let's run another PowerShell command to see which disks I have registered:

I have those two blobs registered as my disks and this prevents me from directly deleting them which is perfectly reasonable. To prove that this is actually the case, I will view the HTTP headers of one of those disks through CloudBerry Explorer for Azure Blob Storage:

You can see that "x-ms-lease-status" header is set to "locked" which states that there is a lease on the blob. Let's remove the "IstBootcampDemoTugberk-IstBootcampVM1-2013-4-27-132" disk from my registered disks:

Now, let's look at the HTTP headers of the blob again:

The lease is now taken out and it's now possible to delete the blob:

However, you can delete the disk from your registered disks list and the storage container in one go by running "Remove-AzureDisk" PowerShell Cmdlet with "DeleteVHD" switch:

The VHD file is completely gone. I hope the post was helpful

Windows Azure PowerShell Cmdlets In a Nutshell

Fri, 26 Apr 2013 08:05:00 Z

Managing your Windows Azure services is super easy with the various management options and my favorite among these options is Windows Azure PowerShell Cmdlets. It's very well-documented and if you know PowerShell enough, Windows Azure PowerShell Cmdlets are really easy to grasp. In this post I would like to give a few details about this management option and hopefully, it'll give you a head start.

Install it and get going

Installation of the Windows Azure PowerShell Cmdlets is very easy. It's also well-documented. You can reach the download link from the "Downloads" section on Windows Azure web site. From there, all you need to do is follow the instructions to install the Cmdlets through Web Platform Installer.

After the installation, we can view that we have the Windows Azure PowerShell Cmdlets installed on our system by running "Get-Module -ListAvailable" command:

To get you started using Cmdlets, you can see the "Get Started with Windows Azure Cmdlets" article which explains how you will set up the trust between your machine and your Windows Azure account. However, I will cover some steps here as well.

First thing you need to do is download your publish settings file. There is a handy cmdlet to do this for you: Get-AzurePublishSettingsFile. By running this command, it will go to your account and create a management certificate for your account and download the necessary publish settings file.

Next step is to import this publish settings file through another handy cmdlet: Import-AzurePublishSettingsFile <publishsettings-file-path>. This command is actually setting up lots of stuff on your machine.

Under "%appdata%\Windows Azure Powershell", it creates necessary configuration files for the cmdlets to get the authentication information.

These configuration files don't actually contain certificate information on its own; they just hold the thumbprint of our management certificate and your subscription id.
Actual certificate is imported inside your certificate store. You can view the installed certificate by running "dir Cert:\CurrentUser\My" command.

Now you are ready to go. Run "Get-AzureSubscription" command to see your subscription details and you will see that it's set as your default subscription. So, from now on, you don't need to do anything with your subscription. You can just run the commands without worrying about your credentials (of course, this maybe a good or bad thing; depends on your situation). For example, I ran the Get-AzureVM command to view my VMs:

So, where is my stuff?

We installed the stuff and we just saw that it's working. So, where did all the stuff go and how does this thing even work? Well, if you know PowerShell, you also know that modules are stored under specific folders. You can view these folders by running the '$env:PSModulePath.split(';')' command:

Notice that there is a path for Windows Azure PowerShell Cmdlets, too. Without knowing this stuff, we could also view the module definition and get to its location from there:

Get-Module -ListAvailable -Name Azure

"C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure" directory is where you will find the real meat:

On the other hand, when we imported the publish settings, it puts a few stuff about my subscription under "%appdata%\Windows Azure Powershell". The certificate is also installed under my certificate store as mentioned before.

Clean Up

When you start managing your Windows Azure services through PowerShell Cmdlets, you have your Windows Azure account information and management certificate information at various places on your computer. Even if you uninstall your Windows Azure PowerShell Cmdlets from your machine, you are not basically cleaning up everything. Let's start by uninstalling the Cmdlets from your computer.

Simply go to Control Panel > Programs > Programs and Features and find the installed program named as Windows Azure PowerShell and uninstall it. You will be done.

Next step is to go to "%appdata%\Windows Azure Powershell" directory and delete the folder completely. One more step to go now: delete your certificate. Find out what the thumbprint of your certificate is:

Then, run the Remove-Item command to remove the certificate:

Remove-Item Cert:\CurrentUser\My\507DAAF6F285C4A72A45909ACCEE552B4E2AE916 –DeleteKey

You are all done uninstalling Windows Azure PowerShell Cmdlets. Remember, Windows Azure is powerful but it's more powerful when you manage it through PowerShell

References

SignalR and Real-time Web Application Scenarios Webcast Recording (In Turkish) is Available

Mon, 22 Apr 2013 05:52:00 Z

A few days ago, I presented on a webcast about ASP.NET SignalR and real-time web application scenarios in Turkish and it went pretty great I think. I also managed to record the webcast successfully and put it on Vimeo.

SignalR ve Realtime Web Uygulama Senaryoları from Tugberk Ugurlu on Vimeo.

Hope you'll like it

Istanbul Part of Global Windows Azure Bootcamp Events

Fri, 19 Apr 2013 18:28:00 Z

Global Windows Azure Bootcamp will be happening on the 27th of April, 2013 all over the World and Istanbul will be also hosting one of these events. Global Windows Azure Bootcamp Istanbul will be held at Microsoft Istanbul office and the registration is open. You can register the event through Eventbrite.

Daron Yondem, Ilkay Ilknur and myself will be presenting on several topics and you can view the list of sessions on the event registration page as well. See you there

Links, Source Code and Slides From My Microsoft Web Camp Talks

Sun, 07 Apr 2013 19:01:00 Z

Within the Microsoft Web Camps Spring 2013 Tour, Web Camp Istanbul was held at Microsoft Istanbul office and we had such an incredible, enjoyable event. During the day, Jon Galloway, Umit Sunar and myself presented several topics including Windows Azure, ASP.NET MVC, ASP.NET Web API and ASP.NET SignalR.

During the day, I helped Jon by trying to be the dummy guy during his ASP.NET MVC presentation. I also presented on ASP.NET Web API and ASP.NET SignalR where I showed a few sample applications. You could find the source code for those samples on my GitHub repository: https://github.com/tugberkugurlu/IstanbulWebCamps201304.

You can also find the slides for the ASP.NET Web API session: ASP.NET Web API Intro - Microsoft Web Camp, Istanbul. Here are also some links for the stuff that I have mentioned during the sessions.

ASP.NET SignalR

ASP.NET Web API

Building Services for Any Client with ASP.NET Web API
ASP.NET Web API Tutorials
ASP.NET Web API Samples
Contact Manager - An ASP.NET Web API Sample Application (Including a Windows 8 Client)
ASP.NET Web API Book (You can get the alpha version of Pro ASP.NET Web API book on Apress today)
Fiddler

I would like to thank Jon Galloway for coming to Istanbul for this event and allowing us to have such a fun day. I personally really enjoyed the whole event and also the small Istanbul tour I had with Jon I also would like to thank Brady Gaster as he's one of the people who made this event happen. I'm hoping that we will keep seeing these types of web events in Istanbul more

Basics of Git Rebase

Sat, 30 Mar 2013 20:18:00 Z

You may wonder why the title starts with "Basics". The answer is simple: I know only the basics of git rebase :) It's only one of the powerful features of git and it allows you to have a clean history in a highly branching workflow. "Rebase" is quite powerful as mentioned and what I'm about to show you is only one of the reasons why to use rebase. I highly recommend Keith Dahlby's NDC talk which he took some time to show the rebase feature.

Let's see the easiest sample where rebase comes handy. We have the following history where we have two branches: master and feature-1.

Typically, what you would do here is to merge the feature-1 branch onto master which is fairly reasonable and it works. However, it creates you a unnecessary commit + a ridiculous graph which would be a mess if you think of hundreds of branches:

What you can do with rebase is to patch the feature-1 branch onto master. Later then, you can merge from there. The following command is what you need to run:

After running the rebase command, we can run "gitk –all" to see the graph:

It's now nice clean history. Notice that the master is still pointing where it was. It's because we haven't merge the feature-1 branch yet. Let's checkout to master branch and run "git merge feature-1" to merge feature-1 branch onto master branch:

Nicely done! Open up the gitk one more time and see the clean history:

After we remove the feature-1 branch by running "git branch –D feature-1", we won't have any trace from feature-1 branch which is absolutely OK as feature branches are just the implementation details, that's all.

Rebase can hurt

With git rebase, at the very basic level, you are messing with the history which can be dangerous depending on the case. On the other hand, when you have a collision, it's not a picnic to solve those collisions with interactive rebase without a deep firsthand knowledge but it's worth looking into even if it seems hard at the first glance

Microsoft Web Camps Istanbul on the 6th of April

Sat, 23 Mar 2013 18:21:00 Z

This is an awesome news that I am proud of to write about. I think it all started out with my reply to Brady Gaster on twitter:

@bradygaster I would like to see a blog post from you titled as "Kicking off Web Camps Turkey".
— Tugberk Ugurlu (@tourismgeek) January 24, 2013

And it's now a real deal thanks to awesome Web Camps team! One leg of Microsoft Web Camps spring 2013 tour will be held in Microsoft Istanbul office on the 6th of April, 2013. It will be a full day event. Jon Galloway, Umit Sunar and me will be giving talks on various latest Microsoft Web Stack technologies including Windows Azure, ASP.NET Web API, ASP.NET SignalR, ASP.NET MVC and so on. You can see the typical agenda of Web Camps here.

You can also find more about Web Camps spring 2013 tour from Jon Galloway's and Brady Gaster's blog posts:

Announcing Web Camps Spring Tour 2013 by Jon Galloway
Web Camps Dallas by Brady Gaster

There are finite number of seats available. So, register ASAP to participate this great event from the following link:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032548038&Culture=TR-TR&community=0

See you at Web Camps

MSP Turkey Kickoff Microsoft Web Stack Presentation Slides, Samples and Links

Sat, 09 Feb 2013 14:22:00 Z

I was at MSFT Istanbul office yesterday to give a presentation on Microsoft Web Stack for MSPs. It went pretty well I think. It was mostly focused on ASP.NET MVC 4, SignalR and ASP.NET Web API. You can get the slides for the presentation from my Speakerdeck account.

Source code for the sample applications I showed is available on GitHub: https://github.com/tugberkugurlu/MSPKickOff201302MSFTWebStack.

I also showed the Electric Plum's iPhone and iPad simulator and I used it right from VS. I followed through this awesome blog post from Scott Hanselman to set this up: Simulating an iPhone or iPad browser for ASP.NET Mobile Web Development with WebMatrix 2 or Visual Studio 2012. You can do the same. Here are a few other links which were touched upon during the presentation:

General Links

ASP.NET MVC

ASP.NET SignalR

ASP.NET Web API

Building Services for Any Client with ASP.NET Web API
ASP.NET Web API Tutorials
ASP.NET Web API Book (You can get the alpha version of Pro ASP.NET Web API book on Apress today)
Fiddler

I would like to thank our MVP Lead Sinem Eylem Arslan and Mustafa Kasap for the opportunity. Also, special thanks go to XOMNI team (Daron Yondem, Gökhan Gülbiz, ilkay ilknur) for helping me to get though those 2 days in Istanbul. I have to say this: they seriously know how to live Breakfast was amazing

Autofac Open Generics Feature to Register Generic Services

Tue, 05 Feb 2013 10:46:00 Z

This is going to be a quick and dirty blog post but hopefully, will take this giant stupidity out of me. Autofac, an awesome IoC container for .NET platform, has an out of the box generic service registration feature and I assume nearly all IoC containers have this today which makes me feel stupid because I have been knowing this for only a month or so I was doing something like below before.

private static void RegisterRepositories(ContainerBuilder builder) {
 
    Type baseEntityType = typeof(BaseEntity);
    Assembly assembly = baseEntityType.Assembly;
    IEnumerable<Type> entityTypes = assembly.GetTypes().Where(
        x => x.IsSubclassOf(baseEntityType));
        
    foreach (Type type in entityTypes) {
 
        builder.RegisterType(typeof(EntityRepository<>)
               .MakeGenericType(type))
               .As(typeof(IEntityRepository<>).MakeGenericType(type))
               .InstancePerApiRequest();
    }
}

Then, Ben Foster pinged me on twitter:

@tourismgeek what, no For(type of(IFoo<>).Use(typeof(Foo<>)? Even Ninject supports that.
— Ben Foster (@benfosterdev) December 19, 2012

This tweet made me look for alternative approaches and I found out the Autofac's generic service registration feature. Here is how it looks like now:

private static void RegisterRepositories(ContainerBuilder builder) {
 
    builder.RegisterGeneric(typeof(EntityRepository<>))
           .As(typeof(IEntityRepository<>))
           .InstancePerApiRequest();
}

Way better! Autofac also respects generic type constraints. Here is a quote from the Autofac documentation:

Autofac respects generic type constraints. If a constraint on the implementation type makes it unable to provide a service the implementation type will be ignored.

If you didn't know this feature before, you do know it now Enjoy it!

Hierarchical Resource Structure in ASP.NET Web API

Mon, 04 Feb 2013 10:11:00 Z

I came across a question on Stackoverflow today about the hierarchical resource structure in ASP.NET Web API: http://stackoverflow.com/questions/14674255. The question is basically about the following issue:

I have the following schema that I'd like to implement in ASP.NET Web API. What is the proper approach?

http://mydomain/api/students
http://mydomain/api/students/s123
http://mydomain/api/students/s123/classes
http://mydomain/api/students/s123/classes/c456

With this nice hierarchical approach, you have more concerns that routing here in terms of ASP.NET Web API. There is a good sample application which adopts the hierarchical resource structure: PingYourPackage. I definitely suggest you to check it out.

Let me explain the concerns here in details by setting up a sample scenario. This may not be the desired approach for these types of situations but lays out the concerns very well and if you have a better way to eliminate these concerns, I'd be more that happy to hear those.

Let's say you have the below two affiliates inside your database for a shipment company:

Affiliate1 (Id: 100)
Affiliate2 (Id: 101)

And then assume that these affiliates have some shipments attached to them:

Affiliate1 (Key: 100)
- Shipment1 (Key: 100)
- Shipment2 (Key: 102)
- Shipment4 (Key: 104)
Affiliate2 (Key: 101)
- Shipment3 (Key: 103)
- Shipment5 (Key: 105)

Finally, we want to have the following resource structure:

GET api/affiliates/{key}/shipments
GET api/affiliates/{key}/shipments/{shipmentKey}
POST api/affiliates/{key}/shipments
PUT api/affiliates/{key}/shipments/{shipmentKey}
DELETE api/affiliates/{key}/shipments/{shipmentKey}

In view of ASP.NET Web API, we have three obvious concerns here: routing, authorization and ownership. Let's go through this one by one.

The below code snippets have been taken from the PingYourPackage source code. They won't probably work if you copy and paste them but you will get the idea.

Routing Concerns

Assume that we are sending a GET request against /api/affiliates/105/shipments/102 (considering our above scenario). Notice that the affiliate key is 105 here which doesn't exist. So, we would want to terminate the request here ASAP. We can achieve this with a per-route message handler as early as possible. The following AffiliateShipmentsDispatcher is responsible for checking the affiliate existence and acting on the result.

public class AffiliateShipmentsDispatcher : DelegatingHandler {

  protected override Task<HttpResponseMessage> SendAsync(
      HttpRequestMessage request, 
      CancellationToken cancellationToken) {

      // We know at this point that the {key} route variable has 
      // been supplied. Otherwise, we wouldn't be here. So, just get it.
      IHttpRouteData routeData = request.GetRouteData();
      Guid affiliateKey = Guid.ParseExact(routeData.Values["key"].ToString(), "D");

      IShipmentService shipmentService = request.GetShipmentService();
      if (shipmentService.GetAffiliate(affiliateKey) == null) {

          return Task.FromResult(
              request.CreateResponse(HttpStatusCode.NotFound));
      }

      return base.SendAsync(request, cancellationToken);
  }
}

I am here using a few internal extension methods which are used inside the project but the idea is simple: go to the database and check the existence of the affiliate. If it doesn't exist, terminate the request and return back the "404 Not Found" response. If it exists, continue executing by calling the base.SendAsync method which will invoke the next message handler inside the chain. Which message handler is the next here? Good question, you dear reader! It's going to be the HttpControllerDispatcher which basically puts us inside the controller pipeline. To attach this handler to a route, we need to create a pipeline first to include the controller pipeline by chaining AffiliateShipmentsDispatcher and HttpControllerDispatcher together. The following code snippet shows the AffiliateShipmentsHttpRoute registration.

public class RouteConfig {

    public static void RegisterRoutes(HttpConfiguration config) {

        var routes = config.Routes;

        // Pipelines
        HttpMessageHandler affiliateShipmentsPipeline =
            HttpClientFactory.CreatePipeline(
                new HttpControllerDispatcher(config),
                new[] { new AffiliateShipmentsDispatcher() });

        // Routes
        routes.MapHttpRoute(
            "AffiliateShipmentsHttpRoute",
            "api/affiliates/{key}/shipments/{shipmentKey}",
            defaults: new { controller = "AffiliateShipments", shipmentKey = RouteParameter.Optional },
            constraints: null,
            handler: affiliateShipmentsPipeline);

        routes.MapHttpRoute(
            "DefaultHttpRoute",
            "api/{controller}/{key}",
            defaults: new { key = RouteParameter.Optional },
            constraints: null);
    }
}

Authorization Concerns

If you have some type of authentication in place, you would want to make sure (in our scenario here) that the authenticated user and the requested affiliate resource is related. For example, assume that Affiliate1 is authenticated under the Affiliate role and you have the AuthorizeAttribute registered to check the "Affiliate" role authorization. In this case, you will fail miserably because this means that Affiliate1 can get to the following resource: /api/affiliates/101/shipments which belongs to Affiliate2. We can eliminate this problem with a custom AuthorizeAttribute which is similar to below one:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public class AffiliateShipmentsAuthorizeAttribute : AuthorizeAttribute {

    public AffiliateShipmentsAuthorizeAttribute() {

        base.Roles = "Affiliate";
    }

    public override void OnAuthorization(HttpActionContext actionContext) {
        
        base.OnAuthorization(actionContext);

        // If not authorized at all, don't bother checking for the 
        // user - affiliate relation
        if (actionContext.Response == null) { 

            // We are here sure that the request has been authorized and 
            // the user is in the Affiliate role. We also don't need 
            // to check the existence of the affiliate as it has 
            // been also already done by AffiliateShipmentsDispatcher.

            HttpRequestMessage request = actionContext.Request;
            Guid affiliateKey = GetAffiliateKey(request.GetRouteData());
            IPrincipal principal = Thread.CurrentPrincipal;
            IShipmentService shipmentService = request.GetShipmentService();
            bool isAffiliateRelatedToUser =
                shipmentService.IsAffiliateRelatedToUser(
                    affiliateKey, principal.Identity.Name);

            if (!isAffiliateRelatedToUser) {

                // Set Unauthorized response as the user and 
                // affiliate isn't related to each other. You might
                // want to return "404 NotFound" response here if you don't
                // want to expose the existence of the affiliate.
                actionContext.Response = 
                    request.CreateResponse(HttpStatusCode.Unauthorized);
            }
        }
    }

    private static Guid GetAffiliateKey(IHttpRouteData routeData) {

        var affiliateKey = routeData.Values["key"].ToString();
        return Guid.ParseExact(affiliateKey, "D");
    }
}

This will be registered at the controller level for the AffiliateShipmentsController.

Ownership Concerns

Consider this URI for an HTTP GET request: /api/affiliates/100/shipments/102. This URI should get us the correct data. However, what would happen for the this URI: /api/affiliates/100/shipments/103? This should get you a "404 Not Found" HTTP response because the affiliate whose Id is 100 doesn't own the shipment whose id is 103. Inside the PingYourPackage project, I ensured the ownership of the resource with the following authorization filter which will be applied to proper action methods.

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class EnsureShipmentOwnershipAttribute 
    : Attribute, IAuthorizationFilter {

    private const string ShipmentDictionaryKey = 
        "__AffiliateShipmentsController_Shipment";
        
    public bool AllowMultiple { get { return false; } }

    public Task<HttpResponseMessage> ExecuteAuthorizationFilterAsync(
        HttpActionContext actionContext,
        CancellationToken cancellationToken,
        Func<Task<HttpResponseMessage>> continuation) {

        // We are here sure that the user is authanticated and request 
        // can be kept executing because the AuthorizeAttribute has 
        // been invoked before this filter's OnActionExecuting method.
        // Also, we are sure that the affiliate is associated with
        // the currently authanticated user as the previous action filter 
        // has checked against this.
        IHttpRouteData routeData = actionContext.Request.GetRouteData();
        Uri requestUri = actionContext.Request.RequestUri;

        Guid affiliateKey = GetAffiliateKey(routeData);
        Guid shipmentKey = GetShipmentKey(routeData, requestUri);

        // Check if the affiliate really owns the shipment
        // whose key came from the request. We don't need to check the 
        // existence of the affiliate as this check has been already 
        // performed by the AffiliateShipmentsDispatcher.
        IShipmentService shipmentService = 
            actionContext.Request.GetShipmentService();
        Shipment shipment = shipmentService.GetShipment(shipmentKey);

        // Check the shipment existance
        if (shipment == null) {

            return Task.FromResult(
                new HttpResponseMessage(HttpStatusCode.NotFound));
        }

        // Check the shipment ownership
        if (shipment.AffiliateKey != affiliateKey) {

            // You might want to return "404 NotFound" response here 
            // if you don't want to expose the existence of the shipment.
            return Task.FromResult(
                new HttpResponseMessage(HttpStatusCode.Unauthorized));
        }

        // Stick the shipment inside the Properties dictionary so 
        // that we won't need to have another trip to database.
        // The ShipmentParameterBinding will bind the Shipment param
        // if needed.
        actionContext.Request
            .Properties[ShipmentDictionaryKey] = shipment;

        // The request is legit, continue executing.
        return continuation();
    }

    private static Guid GetAffiliateKey(IHttpRouteData routeData) {

        var affiliateKey = routeData.Values["key"].ToString();
        return Guid.ParseExact(affiliateKey, "D");
    }

    private static Guid GetShipmentKey(
        IHttpRouteData routeData, Uri requestUri) {

        // We are sure at this point that the shipmentKey value has been
        // supplied (either through route or quesry string) because it 
        // wouldn't be possible for the request to arrive here if it wasn't.
        object shipmentKeyString;
        if (routeData.Values.TryGetValue("shipmentKey", out shipmentKeyString)) {

            return Guid.ParseExact(shipmentKeyString.ToString(), "D");
        }

        // It's now sure that query string has the shipmentKey value
        var quesryString = requestUri.ParseQueryString();
        return Guid.ParseExact(quesryString["shipmentKey"], "D");
    }
}

Now, this filter can be applied to proper action methods to allow the proper authorization. At the very end, the AffiliateShipmentsController class looks clean and readable:

[AffiliateShipmentsAuthorize]
public class AffiliateShipmentsController : ApiController {

    // We are OK inside this controller in terms of 
    // Affiliate existance and its relation with the current 
    // authed user has been checked by the handler 
    // and AffiliateShipmentsAuthorizeAttribute.

    // The action method which requests the shipment instance:
    // We can just get the shipment as the shipment 
    // existance and its ownership by the affiliate has been 
    // approved by the EnsureShipmentOwnershipAttribute.
    // The BindShipmentAttribute can bind the shipment from the
    // Properties dictionarty of the HttpRequestMessage instance
    // as it has been put there by the EnsureShipmentOwnershipAttribute.

    private const string RouteName = "AffiliateShipmentsHttpRoute";
    private readonly IShipmentService _shipmentService;

    public AffiliateShipmentsController(IShipmentService shipmentService) {

        _shipmentService = shipmentService;
    }

    public PaginatedDto<ShipmentDto> GetShipments(
        Guid key, 
        PaginatedRequestCommand cmd) {

        var shipments = _shipmentService
            .GetShipments(cmd.Page, cmd.Take, affiliateKey: key);

        return shipments.ToPaginatedDto(
            shipments.Select(sh => sh.ToShipmentDto()));
    }

    [EnsureShipmentOwnership]
    public ShipmentDto GetShipment(
        Guid key, 
        Guid shipmentKey, 
        [BindShipment]Shipment shipment) {

        return shipment.ToShipmentDto();
    }

    [EmptyParameterFilter("requestModel")]
    public HttpResponseMessage PostShipment(
        Guid key, 
        ShipmentByAffiliateRequestModel requestModel) {

        var createdShipmentResult =
            _shipmentService.AddShipment(requestModel.ToShipment(key));

        if (!createdShipmentResult.IsSuccess) {

            return new HttpResponseMessage(HttpStatusCode.Conflict);
        }

        var response = Request.CreateResponse(HttpStatusCode.Created,
            createdShipmentResult.Entity.ToShipmentDto());

        response.Headers.Location = new Uri(
            Url.Link(RouteName, new { 
                key = createdShipmentResult.Entity.AffiliateKey,
                shipmentKey = createdShipmentResult.Entity.Key
            })
        );

        return response;
    }

    [EnsureShipmentOwnership]
    [EmptyParameterFilter("requestModel")]
    public ShipmentDto PutShipment(
        Guid key, 
        Guid shipmentKey,
        ShipmentByAffiliateUpdateRequestModel requestModel,
        [BindShipment]Shipment shipment) {

        var updatedShipment = _shipmentService.UpdateShipment(
            requestModel.ToShipment(shipment));

        return updatedShipment.ToShipmentDto();
    }

    [EnsureShipmentOwnership]
    public HttpResponseMessage DeleteShipment(
        Guid key, 
        Guid shipmentKey,
        [BindShipment]Shipment shipment) {

        var operationResult = _shipmentService.RemoveShipment(shipment);

        if (!operationResult.IsSuccess) {

            return new HttpResponseMessage(HttpStatusCode.Conflict);
        }

        return new HttpResponseMessage(HttpStatusCode.NoContent);
    }
}

As said, I'd love to know how you handle these types of situations in your applications.

Installing hub Extension for Git (by defunkt) on Windows to Work With GitHub More Efficiently

Sat, 19 Jan 2013 22:10:00 Z

We are all in love with Git but without GitHub, we love Git less. On GitHub, we can maintain our projects very efficiently. Pull Request” and "Issues" features of GitHub are the key factors for that IMO. You can even send yourself a pull request from one branch to another and discuss that particular change with your team. As your discussion flows, your code can flow accordingly, too. This is just one of the many coolest features of GitHub.

There is a cool Git extension for GitHub which is maintained by one of the founders of GitHub: Chris Wanstrath. This cool extension named hub lets us work with GitHub more efficiently from the command line and perform GitHub specific operations easily like sending pull requests, forking repositories, etc. It’s fairly easy to install it on other platforms as far as I can see but it’s not that straight forward for Windows.

You should first go and install msysgit on Windows and I am assuming most of us using this on Windows for Git. Secondly, we should install Ruby on windows. You can install Ruby on windows through RubyInstaller easily.

After installing ruby on our machine successfully, we should add the bin path of Ruby to our system PATH variable. In order to do this, press Windows Key + PAUSE BREAK to open up the Windows System window and click "Advanced system settings" link on the left hand side of the window.

A new window should appear. From there, click "Environment Variables..." button to open up the Environment Variables window.

From there, you should see "System variables" section. Find the Path variable and concatenate the proper ruby bin path to that semicolon-separated list.

Last step is actually installing the hub. You should grab the standalone file and then rename it to "hub". Then, put it under the Git\bin folder. The full path of my Git\bin folder on my 64x machine is "C:\Program Files (x86)\Git\bin".

Now you should be able to run hub command from Git Bash:

Special GitHub commands you get through hub extension is nicely documented on the "Readme" file of the project. I think the coolest feature of hub is the pull-request feature. On GitHub, You can send pull requests to another repository through GitHub web site or GitHub API and hub extension uses GitHub API under the covers to send pull requests. You can even attach your pull request to an existing issue. For example, the following command sends a pull request to master branch of the tugberkugurlu’s repository from the branch that I am currently on and attaches this to an existing issue #1.

hub pull-request -i 1 -b tugberkugurlu:master

Have fun

ASP.NET Web API Tracing and IDependencyScope Dispose Issue

Sat, 12 Jan 2013 18:26:00 Z

ASP.NET Web API has a very cool built-in tracing mechanism. The coolest part about this feature is that none of the tracing code is being run if you don’t enable it. The mechanism makes use of well-known Facade Pattern and if you enable tracing by providing your custom ITraceWriter implementation and don’t replace the default ITraceManager implementation, several ASP.NET Web API components (Message Handlers, Controllers, Filters, Formatters, etc.) will be wrapped up inside their tracer implementations (these are internal classes inside System.Web.Http assembly). You can learn more about tracing from Tracing in ASP.NET Web API article.

ASP.NET Web API also has this concept of carrying disposable objects inside the request properties bag and two objects are added to this disposable list by the framework as shown below (in the same order):

The IDependencyScope implementation for the request.
The selected IHttpController implementation for the request.

The DisposeRequestResources extension method for the HttpRequestMessage object is invoked by the hosting layer at the end of each request to dispose the registered disposable objects. The invoker is the internal ConvertResponse method of HttpControllerHandler in case of ASP.NET host. The implementation of the DisposeRequestResources extension method is exactly as shown below:

public static void DisposeRequestResources(this HttpRequestMessage request) {

    if (request == null) {
        throw Error.ArgumentNull("request");
    }

    List<IDisposable> resourcesToDispose;
    if (request.Properties.TryGetValue(HttpPropertyKeys.DisposableRequestResourcesKey, out resourcesToDispose)) {
        foreach (IDisposable resource in resourcesToDispose) {
            try {
                resource.Dispose();
            }
            catch {
                // ignore exceptions
            }
        }
        resourcesToDispose.Clear();
    }
}

It iterates through the list and disposes the registered objects one by one. So far so good. However, there is one slightly problem here depending on your ITraceWriter implementation. I’m not sure if it’s fair to call this a bug, but to me, it really is a bug. Let me explain what it is.

As we know, the IDependencyScope implementation and the selected IHttpController implementation for the request are added to the disposables list in order to be disposed at the end of the request. As we also know, if we enable tracing in ASP.NET Web API, several ASP.NET Web API components wrapped inside their tracer implementations. In case of controllers, this is HttpControllerTracer. Since the IHttpController is also disposable, the HttpControllerTracer overrides the Dispose method to write a begin/end trace record for the dispose action. However, the disposable objects are disposed in order and when the controller’s dispose method is called, the dependency scope is already too far gone and if your custom ITraceWriter implementation tries to use the dependency scope, which is bound to that request, you will get an exception there. This doesn’t effect your application that much as this exception is swollen by the underlying infrastructure but this is not good. I wrote a little application to demonstrate this (actually, I went a little far and used a few more things for this *little* application ) and show how to workaround it for now. The code for this project is available on GitHub.

I created a custom tracer and registered through the global HttpConfiguration instance. This tracer tries to reach the ILoggerService implementation through the dependency scope. The code for my ITraceWriter implementation is as shown below:

public class WebApiTracer : ITraceWriter {

    public void Trace(
        HttpRequestMessage request, 
        string category, 
        TraceLevel level, 
        Action<TraceRecord> traceAction) {

        if (level != TraceLevel.Off) {

            TraceRecord record = new TraceRecord(request, category, level);
            traceAction(record);
            Log(record);
        }
    }

    private void Log(TraceRecord traceRecord) {

        IDependencyScope dependencyScope = 
            traceRecord.Request.GetDependencyScope();
            
        ILoggerService loggerService = 
            dependencyScope.GetService(typeof(ILoggerService)) as ILoggerService;
            
        // Log the trace data here using loggerService
        
        // Lines omitted for brevity
    }
}

When we run this application in debug mode and send a request against a valid resource which will eventually go inside the controller pipeline (for this application /api/cars), we will see an exception as below:

If we are curios enough and decide to dig a little deeper, we will actually see what is causing this exception.

{"Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it has already been disposed."}

   at Autofac.Core.Lifetime.LifetimeScope.CheckNotDisposed()
   at Autofac.Core.Lifetime.LifetimeScope.ResolveComponent(IComponentRegistration registration, IEnumerable`1 parameters)
   at Autofac.ResolutionExtensions.TryResolveService(IComponentContext context, Service service, IEnumerable`1 parameters, Object& instance)
   at Autofac.ResolutionExtensions.ResolveOptionalService(IComponentContext context, Service service, IEnumerable`1 parameters)
   at Autofac.ResolutionExtensions.ResolveOptional(IComponentContext context, Type serviceType, IEnumerable`1 parameters)
   at Autofac.ResolutionExtensions.ResolveOptional(IComponentContext context, Type serviceType)
   at Autofac.Integration.WebApi.AutofacWebApiDependencyScope.GetService(Type serviceType)
   at DependencyScopeTracingDisposeBug.Tracing.WebApiTracer.Log(TraceRecord traceRecord) in e:\Apps\DependencyScopeTracingDisposeBug\Tracing\WebApiTracer.cs:line 25
   at DependencyScopeTracingDisposeBug.Tracing.WebApiTracer.Trace(HttpRequestMessage request, String category, TraceLevel level, Action`1 traceAction) in e:\Apps\DependencyScopeTracingDisposeBug\Tracing\WebApiTracer.cs:line 18
   at System.Web.Http.Tracing.ITraceWriterExtensions.TraceBeginEnd(ITraceWriter traceWriter, HttpRequestMessage request, String category, TraceLevel level, String operatorName, String operationName, Action`1 beginTrace, Action execute, Action`1 endTrace, Action`1 errorTrace)
   at System.Web.Http.Tracing.Tracers.HttpControllerTracer.System.IDisposable.Dispose()
   at System.Net.Http.HttpRequestMessageExtensions.DisposeRequestResources(HttpRequestMessage request)

It wasn’t hard to diagnose the problem and the question was how to workaround it for now as the issue is caused by a code which is deep inside the bowel of the hosting layer. There are several workarounds for this problem which I can come up with quickly such as replacing the HttpControllerTracer but the one I applied was very dirty: adding a message handler as the first message handler (so that it runs last (just in case)) and reordering the disposables on the way out. Here is the message handler which performs this operation:

public class DisposableRequestResourcesReorderHandler : DelegatingHandler {

    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken) {

        return base.SendAsync(request, cancellationToken).Finally(() => {

            List<IDisposable> disposableResources = 
                request.Properties[HttpPropertyKeys.DisposableRequestResourcesKey] as List<IDisposable>;
                
            if (disposableResources != null && disposableResources.Count > 1) {

                // 1-) Get the first one (which I know is AutofacWebApiDependencyScope).
                // 2-) Remove it from the list.
                // 3-) Push it at the end of the list.

                IDisposable dependencyScope = disposableResources[0];
                disposableResources.RemoveAt(0);
                disposableResources.Add(dependencyScope);
            }
        }, runSynchronously: true);
    }
}

Notice that I used an extension method for Task object called Finally. This is a method which you can get by installing the TaskHelpers NuGet package. This allows you to run the continuation no matter what the status of the completed Task. Finally method will also propagate the proper Task back to the caller, which is kind of nice and clean in our case here as we want to run this code no matter what the status of the Task is.

When you run the application after registering this message handler, you will see the controller’s dispose trace record being logged successfully.

If you believe this is a bug and should be fixed, please vote for this issue: http://aspnetwebstack.codeplex.com/workitem/768.

Clean, Better, and Sexier Generic Repository Implementation for Entity Framework

Thu, 10 Jan 2013 15:00:00 Z

I have written a few blog posts about my experience on applying the Generic Repository pattern to Entity Framework and I even made a NuGet package for my naïve implementation. Even if that looked OK at the time for me, I had troubles about my implementation for couple of reasons:

The implementations inside the NuGet package didn’t allow the developer to share the DbContext instance between repositories (per-request for example).
When the generic repository methods weren’t enough, I was creating new repository interfaces and classes based on the generic ones. This was the biggest failure for me and didn’t scale very well as you can imagine.
There were no pagination support.
As each repository take a direct dependency on DbContext and it is impossible to entirely fake the DbContext, generic repositories needed to be mocked so that we could test with them. However, it would be just very useful to pass a fake DbContext instance into the repository implementation itself and use it as fake.

With the new release of the GenericRepository.EntityFramework package, the all of the above problems have their solutions. The source code for this release is available under the master branch of the repository and you can also see the ongoing work for the final release under the v0.3.0 branch. The NuGet package is available as pre-release for now. So, you need to use the –pre switch to install it.

PM> Install-Package GenericRepository.EntityFramework -Pre

The old GenericRepository.EF package is still around and I will update it, too but it’s now unlisted and only thing it does is to install the GenericRepository.EntityFramework package.

I also included a sample application which shows the usage briefly. I will complete the sample and extend it further for a better view. Definitely check this out!

Let’s dive right in and see what is new and cool.

IEntity and IEntity<TId> Interfaces

I introduced two new interfaces: IEntity and IEntity<TId> and each of your entity classes needs to implement one of these. As you can see from the implementation, IEntity just implements the IEntity<int> and you can use IEntity if you are using integer based Ids. The reason why I added these is make the GetSingle method work.

Use EntitiesContext Instead of DbContext

Instead of deriving your context class from DbContext, you now need to take the EntitiesContext as the base class for your context. If you have an existing context class based on DbContext, changing it to use EntitiesContext should not break it. The EntitiesContext class has all the same constructors as DbContext. So, you can also use those. Here is the sample:

public class AccommodationEntities : EntitiesContext {

    // NOTE: You have the same constructors as the DbContext here. E.g:
    // public AccommodationEntities() : base("nameOrConnectionString") { }

    public IDbSet<Country> Countries { get; set; }
    public IDbSet<Resort> Resorts { get; set; }
    public IDbSet<Hotel> Hotels { get; set; }
}

Then, through your IoC container, you can register your context as a new instance for IEntitiesContext per a particular scope. The below example uses Autofac to do that for an ASP.NET Web API application:

private static void RegisterDependencies(HttpConfiguration config) {

    var builder = new ContainerBuilder();
    builder.RegisterApiControllers(Assembly.GetExecutingAssembly());

    // Register IEntitiesContext
    builder.Register(_ => new AccommodationEntities())
           .As<IEntitiesContext>().InstancePerApiRequest();

    // TODO: Register repositories here

    config.DependencyResolver = 
        new AutofacWebApiDependencyResolver(builder.Build());
}

IEntityRepository<TEntity> and EntityRepository<TEntity>

Here is the real meat of the package: IEntityRepository and EntityRepository. Same as the IEntity and IEntity<TId>, we have two different IEntityRepository generic interfaces: IEntityRepository<TEntity> and IEntityRepository<TEntity, TId>. They have their implementations under the same generic signature: EntityRepository<TEntity> and EntityRepository<TEntity, TId>. The big improvement now is that EntityRepository generic repository implementation accepts an IEntitiesContext implementation through its constructor. This, for example, enables you to use the same DbContext (IEntitiesContext implementation in our case, which is EntitiesContext by default) instance per-request for your ASP.NET MVC, ASP.NET Web API application and share that across your repositories. Note: don’t ever use singleton DbContext instance throughout your AppDomain. DbContext is not thread safe.

As we have registered our EntitiesContext instance per request above, we can now register the repositories as well. As our repositories accepts an IEntitiesContext implementation through their constructor, our IoC container will use our previous registration for that automatically. Autofac has this ability as nearly all IoC containers do.

private static void RegisterDependencies(HttpConfiguration config) {

    var builder = new ContainerBuilder();
    builder.RegisterApiControllers(Assembly.GetExecutingAssembly());

    // Register IEntitiesContext
    builder.Register(_ => new AccommodationEntities())
           .As<IEntitiesContext>().InstancePerApiRequest();

    // TODO: Register repositories here
    builder.RegisterType<EntityRepository<Country>>()
           .As<IEntityRepository<Country>>().InstancePerApiRequest();
    builder.RegisterType<EntityRepository<Resort>>()
           .As<IEntityRepository<Resort>>().InstancePerApiRequest();
    builder.RegisterType<EntityRepository<Hotel>>()
           .As<IEntityRepository<Hotel>>().InstancePerApiRequest();

    config.DependencyResolver = 
        new AutofacWebApiDependencyResolver(builder.Build());
}

Out of the Box Pagination Support

Best feature with this release is out of the box pagination support with generic repository instances. It doesn’t perform the pagination in-memory; it queries the database accordingly and gets only the parts which are needed which is the whole point Here is an ASP.NET Web API controller which uses the pagination support comes with the EntityRepository:

public class CountriesController : ApiController {

    private readonly IEntityRepository<Country> _countryRepository;
    private readonly IMappingEngine _mapper;
    public CountriesController(
        IEntityRepository<Country> countryRepository, 
        IMappingEngine mapper) {

        _countryRepository = countryRepository;
        _mapper = mapper;
    }

    // GET api/countries?pageindex=1&pagesize=5
    public PaginatedDto<CountryDto> GetCountries(int pageIndex, int pageSize) {

        PaginatedList<Country> countries = 
             _countryRepository.Paginate(pageIndex, pageSize);

        PaginatedDto<CountryDto> countryPaginatedDto = 
           _mapper.Map<PaginatedList<Country>, PaginatedDto<CountryDto>>(countries);

        return countryPaginatedDto;
    }
}

public interface IPaginatedDto<out TDto> where TDto : IDto {

    int PageIndex { get; set; }
    int PageSize { get; set; }
    int TotalCount { get; set; }
    int TotalPageCount { get; set; }

    bool HasNextPage { get; set; }
    bool HasPreviousPage { get; set; }

    IEnumerable<TDto> Items { get; }
}

public class PaginatedDto<TDto> : IPaginatedDto<TDto> where TDto : IDto {

    public int PageIndex { get; set; }
    public int PageSize { get; set; }
    public int TotalCount { get; set; }
    public int TotalPageCount { get; set; }

    public bool HasNextPage { get; set; }
    public bool HasPreviousPage { get; set; }

    public IEnumerable<TDto> Items { get; set; }
}

Paginate method will return us the PaginatedList<TEntity> object back and we can project that into our own Dto object as you can see above. I used AutoMapper for that. If I send a request to this API endpoint and ask for response in JSON format, I get back the below result:

{
    "PageIndex":1,
    "PageSize":2,
    "TotalCount":6,
    "TotalPageCount":3,
    "HasNextPage":true,
    "HasPreviousPage":false,
    "Items":[
      {
        "Id":1,
        "Name":"Turkey",
        "ISOCode":"TR",
        "CreatedOn":"2013-01-08T21:12:26.5854461+02:00"
      },
      {
        "Id":2,
        "Name":"United Kingdom",
        "ISOCode":"UK",
        "CreatedOn":"2013-01-08T21:12:26.5864465+02:00"
      }
    ]
}

Isn’t this perfect There are other pagination method inside the EntityRepository implementation which supports including child or parent entities and sorting. You also have the ToPaginatedList extension method and you can build your query and call ToPaginatedList on that query to get PaginatedList<TEntity> object back.

Extending the IEntityRepository<TEntity>

In my previous blog posts, I kind of sucked at extending the generic repository. So, I wanted to show here the better approach that I have been taking for a while now. This is not a feature of my generic repository, this is the feature of .NET itself: extension methods! If you need extra methods for your specific repository, you can always extend the IEntityRepository<TEntity, TId> which gives you a better way to extend your repositories. Here is an example:

public static class HotelRepositoryExtensions {

    public static IQueryable<Hotel> GetAllByResortId(
        this IEntityRepository<Hotel, int> hotelRepository, int resortId) {

        return hotelRepository.FindBy(x => x.ResortId == resortId);
    }
}

What is Next?

My first intention is finish writing all the tests for the whole project, fix bugs and inconsistencies for the v0.3.0 release. After that release, I will work on EF6 version for my generic repository implementation which will have sweet asynchronous support. I also plan to release a generic repository implementation for MongoDB.

Stay tuned, install the package, play with it and give feedback

Sides and Source Code for DEU Bilgisayar Topluluğu Izmir 2. Teknoloji Zirvesi

Tue, 08 Jan 2013 06:34:00 Z

This weekend, I participated in an event as a speaker in Izmir. I also had the chance to meet Fatih Boy, İkay İlknur, Umut Erkal and Oğuzhan Yılmaz at the event. There were great sessions throughout the first and second day.

I gave two talks during the event and one of them was on Git and GitHub. You can see the slides for that session below:

At the second day, I talked about asynchronous programming for .NET server applications. Slides for that session is also available on my SpeakerDeck page. You can also get the source code for the demos: https://github.com/tugberkugurlu/IzmirDEU201301ServerSideAsync.

JavaScript-Heavy, Maintainable Web Applications by a n00b: 101 - Leveraging Existing Libraries

Tue, 08 Jan 2013 02:07:00 Z

Nearly every software developer dedicates a part of its time to improve him/herself on a particular area of expertise. Well, I dedicate this part of my life to JavaScript for a while. I have been writing JavaScript for approx. 3 years now but if anybody asks me if I know JavaScript, I tell them that I know JavaScript and I *don’t* know JavaScript at the same time. It’s probably because of the fact that I don’t get to work with it that much. One of the places I struggle most is the idea of maintaining big-ass JavaScript heavy web applications. That idea has been causing me to carry a psychic weight but now, at this very moment, I am committed to throw it away like a piece of garbage! And yes, it starts with a blog post

A few months ago I talked to a brilliant developer about node.js, the platform built on Chrome's JavaScript runtime (V8) for easily building fast, scalable network applications, and asked his opinion about it. He was uncertain at the time but apparently he had more information about node.js than me. So, I expressed that I didn’t understand the need of JavaScript at the server side because it’s hard to maintain such a huge JS codebase. Then, he slapped me in the face with a follow-up sentence: "Well, the node community thinks that a big application codebase needs to be separated into small modules, components to be more maintainable". That was the nudge I needed to believe that the JavaScript codebase can be maintained.

Not long time later from that moment, I then started watching John Papa’s Single Page Apps with HTML5, Web API, Knockout and jQuery and I learnt lots of mind blowing stuff about JavaScript: new (at least new to me) libraries, well-known JavaScript patterns, which I had been aware of but didn’t know how to apply them most of the time, and many more. This was the start of my commitment to learn JavaScript (I mean really learning, going beyond the for loops and if statements) and I pulled out my JavaScript: The Good Parts book which I have bought in last June, but I thought that the best way to learn this stuff is to blog about it. So, here I am In this post I am listing a few JavaScript libraries which make a lot of sense to be used in nearly every web applications. I have been working with some of this libraries for a while now and I am going to be working with some of those.

JQuery: The JavaScript framework we all know and fell in love at the time that we have noticed it. JQuery is especially helpful for DOM manipulation and Ajax interactions. If you don’t want to install JQuery, don’t worry; you eventually will have to because I am sure that at least of the libraries you are going to use will have a dependency on it.

KnockoutJS: KnockoutJS is one of the best things that can happen to a web developer. Starting to learn KnockoutJS gives you the equivalent feeling which you would feel at the very moment when you find a cup of hot chocolate in a freezing cold day. It enables your to have two way data-binding between your DOM elements and your view model which means when your data model's state changes, your UI updates automatically and vice versa. Check out its well-arranged documents and live tutorials.

Underscore.js: Underscore.js provides a utility suite which covers lots of useful functions. From the its official page: "Underscore provides 80-odd functions that support both the usual functional suspects:map, select, invoke — as well as more specialized helpers: function binding, javascript templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern browsers will use the native implementations of forEach, map,reduce, filter, every, some and indexOf". Don’t forget to watch this awesome presentation from Elijah Manor on Underscore.js.

RequireJS: I think RequireJS is the essential piece of library which makes it possible to have maintainable, well-designed JavaScript codebase. It’s a modular script loader which enables you to write small pieces of code in separate files and handle their dependencies and load order correctly. RequireJS also has a very nice documentation in its web site; definitely check that out.

Sammy.js: Last library I am considering for my every web application is Sammy.js. It gives us a nice way to handle page navigations without refreshing the page at all by providing a nice routing mechanism. Especially, if you are writing a Single Page Applications (SPA), this is the library that you want inside your suite. Don’t skip to check out its intro sample.

There are for sure other great libraries out there (e.g. Moment.js, AmplifyJS, JQuery UI, Breeze) but these are the ones I am in love at the moment. Go check them out and start exploring