SignalR is truly an amazing API. It’s ridiculously easy to use. The majority of SignalR client examples that I see on the web are for HTML/JS or WPF. There are examples for Silverlight but for older version of SignalR and Silverlight. What I was hoping to find was a step by step example using VS2k12, SL5 and latest greatest Nuget Packages. Since I could not find one, I thought I would create one and share. This step by step was highly inspired by the samples found here:
My team has developed several Line of Business applications using Silverlight. Most but not all have at least 3 if not all of the following feature requests:
- Allow users to be signed into the LOB more than once. Users like having more than 1 browser tab or even more than 1 browser type with the LOB app loaded simultaneously.
- Ability to differentiate between a user in Tab1 versus Tab2 for purposes of concurrency, etc.
- Limit the number of simultaneous sessions a specific user can have. 1 is a valid constraint.
- Automatically log out a user instance after X seconds a.k.a session time out
- Gather user information such as browser type/version, screen resolution, IP, etc
- # of concurrent distinct users logged in over time.
- # of concurrent users logged in over time total.
- Max or average simultaneous sessions by users.
All of these are good feature requests for any Line of Business Application. Thinking through it, these features share an implementation detail that requires the LOB to track each signed in user instance.
Here was the plan.
- Create a new database table called AppInstance. This table will contain a list of all the active users in the system.
- Create a new database table called ArchivedAppInstance. This table contains all previously logged in users.
- Whenever a user logs in, add a row to the AppInstance table that records the UserId, timestamp of when that user logged in and any other information your LOB might want to know.
- Whenever a user logs out, archive the #3 AppInstance row to ArchivedAppInstance table noting the logged out timestamp.
The information in these 2 new tables enable the implementation of the features above. Conceptually this is very simple. In fact, 1 through 3 above are easy. #4 it turns out, in Silverlight was not as straight forward as one might think. Why? First, there are multiple ways the application can be exited such as clicking the LOB “Log Out” button, closing the browser directly, navigating away from the LOB web page or, heaven forbid, a browser crash. Except for crashing, the Silverlight application’s Exit event is raised but if you try to perform some backend action like calling a web service it won’t go through since the thread required to make the service call itself is gone.
I worked on a team to solve this. My colleague Tammy McClellan recently documented our approach for other product owners internally and I thought I would share on my blog. In addition, Tammy created an extremely small and simple sample application with our implementation. You can find the code here.
The MVC4 Internet template assumes that it will be adding a user table called “UserProfile” to your database. What I think a high percentage of developers would want is to use their domain model’s “user” entity and have SimpleMembership just manage the passwords. In this blog post I will demonstrate how I did this and welcome alternative suggestions.
I recommend you first understand the authentication process provided by the MVC 4 Internet template. There are 2 fantastic posts you should read first.
- MVC 4 Authentication
- SimpleMembership, Membership Providers, Universal Providers and the new ASP.NET 4.5 Web Forms and ASP.NET MVC 4 templates
MVC 4 Internet Template with pre-existing Domain Model
Create a new ASP.NET MVC 4 Internet Application and name it “SimpleMemberExample”
Custom Domain Model/Database
The first thing I want to do is create the custom domain model/database. In the “Model” directory, lets add a class that represents our custom “User” table. Lets call this custom user entity “Administrator” as seen here:
(I was unable to figure out how my user table’s unique identifier could use a Guid. I think the unique identifier of your custom user entity/table must be an int to use SimpleMembership. anyone know?)
Lets add a custom DbContext as shown here to the root of the project.
The DbContext only contains a single table called Administrators just to keep this super duper easy. Yours would contain lots more. Notice in the custom constructor, I am telling the DbContext to use a specific connection string. Lets add that connection string to the Web.Config.
This connection string could be anything you want it to be.
Just for demo purposes, I am naming the database “SomeAppName”. As a final step, in “Global.asax.cs”, put the following code:
Running the application, the magical EF Code First will create the following database. We have a custom database with a custom user table called “Administrators”.
Customizing MVC 4 Internet Template
The Internet template contains an Action filter called “InitializeSimpleMembershipAttribute”. I deleted that class and removed any references to it.
Replace UserProfile with your Custom User Entity
The Internet template assumes that it will be adding a user table called “UserProfile” to your database. What I think a high percentage of developers would want is to use their domain model’s “user” entity and have SimpleMembership just manage the passwords. Let me demonstrate how to do this.
In the “Model” folder, in the “AccountModel.cs” file, delete the “UserProfile” class. We want to use our “Administrator” entity instead. Wherever UserProfile is referenced elsewhere, replace with Administrator. The original UserProfile had properties called “UserName” and “UserId”. Administrator has properties “Name” and “Id”. Make sure to sync those properties up.
I want to have only 1 DbContext and I want to use my DbContext. In the “Model” folder, in the “AccountModel.cs” file, delete the “UsersContext” class. Wherever UsersContext is referenced elsewhere, replace with SomeAppDbContext.
As a final step, in “Global.asax.cs”, put the following code:
WebSecurity.InitializeDatabaseConnection takes the web.config connection string name, the name of your custom user table (“Administrators”), the unique identifier field name of your user table (“Id”) and the user name field. Running the InitializeDatabaseConnection method does several things:
- Initializes the static Roles and WebSecurity classes.
- Adds the following tables to your database: webpages_Membership, webpages_OAuthMembership, webpages_Roles, webpages_UsersInRoles, UserProfile.
Running the Internet Application
When you run the code with those changes, the following database is created:
The home screen looks like this:
Click on the Register link in the upper right.
Fill out the form and click the “Register” button. The MVC 4 Internet template application will navigate you back to the home page.
Notice it knows the name you registered with. If you check for cookies, you will see the typical ASPXAUTH as shown below.
If you click the “Log off” link and check cookies, the ASPXAUTH cookie disappears. The ASPXAUTH cookie is the key to the authentication.
When you look at the database you will see the following:
Notice with the code changes, the MVC Internet template knew to save to the custom user table “Administrators”. The password was saved to the webpages_Membership table with a foreign key relationship to the Administrators table.
Please download the code here.
I am learning from John Papa’s “Single Page Apps with HTML5, Web API, Knockout and jQuery” on Pluralsight. The course outlines building an application called “Code Camper”. The “Code Camper” sample is very effective at showing an end to end SPA design. It leverages a bunch of open source libraries and can be a lot to take in all at once. One of the libraries used is called Sammy.js. I decided it would beneficial to focus on just Sammy.js library which is the focus of this blog post.
I have had the pleasure of working with some pretty talented U.I. developers. There are some people that can look at a screen 10 feet away and notice a couple of borders are not lined up properly. ProModel refers to these folks as having the “pixel eye”. I do not have the pixel eye unfortunately. I will say however with the increased emphasis on usability and design that I am starting to be more opinionated in this area.
All along I have had a mental concept of what the administrative website would look like. I used Balsamic Mockups and produced the following image.
This is not going to win any awards but it at least gives me a target. ProModel uses Pivotal Tracker and I have always been impressed with the usability of their website. If you look at my design, I was definitely inspired by Pivotal Tracker .
The workflow begins with the user administrator signing in. In my next blog post in this series, i will discuss how to register and authenticate new administrators.
At the end of the last post I had shown a high level overview of some data design patterns such as Repositories and Unit of Work and ended with the browser fetching data from the database for the Application entity of the domain model. In this post, I would like to discuss adding, deleting and updating data through the Web API.
Here is the fully coded ApplicationsController. Notice much of the code is simply delegating to the UoW which in turn simply delegates its work to the generic EFRepository.
At the end of the last post, I had a solution with multiple projects. One of the projects contained the POCO domain model and another project leveraged EF Code First to read/write the domain model to a dynamically created SQL Server database. The goal of this post is to use ASP.NET MVC Web API to surface database data to the client browser.
Most of my career I have spent on the server side of things moving data between layers. I have been part of teams where we created our own application infrastructure as well as a user of IdeaBlade’s DevForce, WCF RIA Services, CSLA, etc.
In the last year, I have had the pleasure of learning from Jon Sarker who is a senior software architect at ProModel. Jon has helped ProModel streamline moving data efficiently and quickly through the use of enterprise design patterns such as Repositories, Commanding, Factories (for repos and commands in particular), DTOs, Request/Response objects, etc. Once you understand and start using these data design patterns, everything seems so modular, clean and maintainable.