We ALWAYS automate our deployments. We always deploy often.
This has many, many benefits. The most important of which is early feedback.
An essential tool when managing deployment of many sites to different environments is a smoke-test page that validates the configuration of the website in that particular environment.
SSW.HealthCheck makes it easy to check your site status.
Figure: SSW.HealthCheck let’s us see at a Glance that on this site: the database connection is valid, but Debug mode has not been turned off and SMTP is not configured. We can also easily extend SSW.HealthCheck to perform other tasks like ensuring your database is up to date. I’ll address this in a future article.
Create a new web project
Lets start with a new web project, then we’ll add SSW.HealthCheck.
Figure: Create a new web project called Northwind.MusicStore.WebUI
Figure: Select the MVC template and click OK.
Optionally: add the ‘Web.API’ and ‘Add unit tests’ options.
Add SSW.HealthCheck.MVC5 to WebUI
Figure: Select Tools | Library Package Manager | Package Manager Console. Enter Install-Package SSW.HealthCheck.MVC5 and press Enter.
Note: Alternatively you can use Tools | Library Package Manager | Manage NuGet Packages for the Solution, and then search for SSW.HealthCheck.MVC5 and click Install.
Figure: Run the application and navigate to /HealthCheck
Configure HealthCheck to Test Your Connection Strings
Figure: Because we are using Entity Framework Code First, and it does not actually create the database until the first time it is accessed: Click the Log In link from the toolbar, enter any username and password and click Log In. Because we are trying to access the database to verify credentials this will cause the database to be created.
Figure: The HealthCheck status of your DefaultConnection should now be Passed !
Also, check out the SSW.HealthCheck user guide here http://sswhealthcheck.com/user-guide/
I am running Windows 8 and Visual Studio on my Mac using Parallels.
The project I am currently working on is configured to use IIS Express, but I want to test it using a VM that contains IE8.
As it turns out this was quite simple to setup.
1. Download the VM from http://www.microsoft.com/en-au/download/details.aspx?id=11575 or http://www.modern.ie/en-gb/virtualization-tools
2. Open the VM using Parallels (File, New, Add Existing Virtual Machine).
3. Change the Windows 8 VM and the VM containing IE8 to both obtain their own IP addresses from the local WiFi router.
Virtual Machine | Configure | Hardware | Network. Change type to WiFi
4. Change the configuration of the web application to use the Windows 8 VMs IP Address
5. Edit the binding in your IIS host config file
(You can find it in %userprofile%\Documents\IISExpress\config\applicationhost.config )
Find the entry for your application and change it from from
<binding protocol=”http” bindingInformation=”*:63527:localhost” />
<binding protocol=”http” bindingInformation=”*:63527:10.0.0.20″ />
6. Disable windows firewall on the Windows 8 machine.
7. Run Visual Studio as Administrator and run the application. It will now be accessible from the IE8 Virtual Machine.
It’s important to consider how strictly you should encapsulate your data access logic within the repository layer
Repository Layers allow us to abstract our data access away from our application.
There are two common approaches.
Approach #1: Fully Encapsulated – The Strict Repository
In this model you pass in simple types or DTOs as parameters to repository methods and receive enumerated lists of results in return. (ie. IEnumerable / ICollection / IList)
Benefit: Your data access is 100% completely abstracted away from your core application.
This model only requires the Entity Framework to be added to your Data project.
Cons: It’s more work. Every data access query requires a new repository method and a change to the interface.
Approach #2: The Flexible Repository
In this model you encapsulate complex queries, or queries that will be re-used inside your repository, but simple queries can be performed by the calling client because the Get() method accepts a filter operator and returns an IQueryable that provides great flexibility.
Benefit: It’s less work. A developer can build user interface that performs simple CRUD operations on the entity without needing to add methods to the Repository.
Cons: This is a ‘leaky’ abstraction where your implementation is likely to leak into your other layers. The Entity Framework is required as a reference in any project where you are performing queries that require EF specific extensions (e.g. .Include(c=>c.Children) )
For each application you need to weight the cons and benefits of the two options.
For a long-lived enterprise application, I recommend fully encapsulated repositories.
For simple applications that are essentially providing forms over data functionality, the flexible repository enables developers to quickly add value to the application, while still leveraging most of the benefits of implementing a repository layer.
TODO: Add Code Samples