It's been a while since I've worked with a true monolithic CMS system like Drupal, but here I am again plugging away and trying to find the best way to work with it (or work around it). I took an absence from using coupled CMS systems for a lot of reasons, first and foremost was the hard dependencies on things like templating, databases and routing. What if I want to choose my database or if server side routing doesn't fulfill my expectations entirely? What if I don't want a denormalized database? As an architect these are all of the things I would love to be able to choose myself, or do I?
Git flow is the most widely used git branching strategy out there, it works... for the most part. It gets the job done, but what if we wanted to avoid planned releases, really switch to an agile methodology and be more productive? Then master only is the strategy for you.
When setting up objects to be shared between the server and client, sometimes the size of them can get a bit out of hand. Normally I don't bother with setting up a fluent api to build objects, but in some cases it may be necessary to hide some of the complexity as well as make it easier to read. This post will show a simple example of how I have implemented it in the past.
In the past, I've generally set up one project as my data layer for not only NHibernate based projects, but other ORMs as well. This is fine for projects that have a moderate amount of domain models, but what if your data layer continues to grow? This post will help describe how to manage your data layer across different projects.
Nancy has a lightweight, low ceremony view engine built right in called the Super Simple View Engine. It has basic functionality that allows you to get the job done for simple sites, but what if you want to do a little more than the view engine offers? This is a good read if you want to know how to extend the SSVE.