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/
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
FireBootCamp has been an amazing experience.
After 9 weeks of intense training, the FireBootCampers present the solutions that they built during the course, celebrate their successes with a glass of Champagne and mingle with potential employers.
When working with the Entity Framework Code First I will often get the error below:
An exception of type “System.Data.SqlClient.SqlException’ occurred in EntityFramework.dll but was not handled by in user code’
Additional information: Cannot drop database [database name] because it is currently in use.
To force a delete of the database, follow the steps below.
Figure: This exception is common after you have opened a LocalDb database in Visual Studio.
Open Library Package Manager and Stop the LocalDb instance
a: Select Tools | Library Package manager | Package Manager Console
b: Execute the following two statements
sqllocaldb stop v11.0
sqllocaldb delete v11.0
Figure: The steps above will stop and delete the LocalDb instance.
Delete the database file from the database
Figure: Open the Solution Explorer and choose Show All Files
Figure: Delete the mdf from the App_Data folder
Sprint 1 was great, but now the guys are really getting going.
Check out their progress in Sprint 2.
Week 1 at FireBootCamp has been amazing.
The teams have been thrown in the deep end, but they are loving it.
They are really getting into learning MVC and Scrum. They especially loved having Andrew Coates from Microsoft as a guest mentor to introduce them to Windows Azure, TFS and Continuous Deployment.
In this video I chat to Michael Crump about his experiences developing for Windows Phone 8.
I caught up with Dino Esposito, Technical Evangelist at JetBrains, to discuss the lessons learnt building mobile apps and sites.
Many of today’s users are on the web via mobile devices, yet too many web sites are neither optimized nor adapted to render on multiple devices. Too many developers think a little CSS magic will do the trick.
Responsive Web Design (RWD) delivers multi-device views without extra costs, but what if you have workflows to implement or different use-cases?
This video session with Dino looks at a few real examples where RWD is not enough and server-side detection is necessary.
If you are a ReSharper user (and you should be), check out the new dependency graph. It is awesome for easily getting a high level view of the dependencies between projects and layers in your solution.
Figure: ReSharper 8 introduces a dependency graph to its architecture tools.
Figure: I structure my solution to reflect the Onion Architecture. http://rules.ssw.com.au/SoftwareDevelopment/RulesToBetterMVC/Pages/The-layers-of-the-onion-architecture.aspx
I have layers for UI, Business Logic Interfaces, Repository Interfaces and the Domain Model. I then inject my dependencies into these layers.
I like to structure the dependencies under a different solution folder so as to emphasise that the dependencies exist outside of the application core.
Figure: R# now generates a dependency graph of your solution (or a selected part of your solution) and by default groups the projects by Solution folders.
I love this because with a few clicks I can get a very clear idea of the dependencies between the different layers in my solution, and see where references exist to dependency projects.
I unselected three items to remove noise from the diagram: the Solution Items folder (which contains the deployment project and documentation), the Common folder (which contains cross-cutting concerns) and the Dependency Resolver project which configures the IOC container.
Figure: I generated the ReSharper dependency diagram as preparation for the first Sprint Review meeting and immediately noticed a dependency from my Client (UI) layer to a ‘Dependency’ project.
No No No No No !!!
Figure: We refactored to inject the dependency into the application core and removed the reference to Data.FileStream from the UI Project.
The dependency graph now looks awesome ! There are no lines from the Clients window to the Dependencies window!
Figure: As a comparison, this is how the Visual Studio Dependency Graph looks when first created. I would usually then remove the outlined items to remove noise.
Figure: After removing the extra projects, my Visual Studio Dependency Graph is more readable, but I would love to see the ability to group projects by Solution Folder.
Figure: The Visual Studio architecture tools are more complete and advanced than the ReSharper ones at present and the Layer Diagram is an invaluable tool that allows you to specify all the layers of your solution, assign projects and classes to particular layers and then have the architecture validated when you build.
What I love about the ReSharper dependency graph is how easy it makes it to get a high level overview of my solution.
It also has the ability to track changes to your architecture as your project progresses, and to indicate metrics. I’ll let you know how these features work out for me as the project progresses.
I was joined by Windows Phone Developer Evangelist Dave Glover from Microsoft to talk about Windows Phone 8 development.
We chat about how far Windows Phone has come since the release of Windows Phone 7, how it is tracking against its competitors, where it fits into the market, and the opportunities for developers in the Windows Phone Marketplace.
In this video, we discuss:
– The range of hardware running the platform
– Key apps for the platform
– How it’s easier to build apps for Windows Phone than any other platform
– What’s new in Windows Phone 8
– How to get your app noticed on the Marketplace