Best practice

Dynamic Azure Web Services URLs

Jun 10th

Posted by dan in Azure

1 comment

I am currently building a lot of web services for Azure. Since URLs change a lot in development and deployment environments I needed to be able to have those services URLs updated dynamically. The easiest way I found is using handlers and:


HttpContext.Current.Request.Headers["Host"];

This way none of the URLs get hard-coded and deployment is extremely easy. This also brings a lot of neat options for Intercloud communication, but that is for another post.

The build process

Feb 11th

Posted by dan in Best practice

No comments

  • Ensure Binary Integrity of your build:
    • The build either works or it does not work. This way it is easier to rule out errors in different layers of the project like database or logic
  • Builds are obtained from files under source control:
    • This means that if a problem happens the error can be linked to a specific commit or tag under version control
  • Build can happen remotely (production) or locally:
    • This allows for the same local configuration to be tested on different environments remotely (production)
    • It can also allow specific special configuration (ex: a tag under version control) to be propagated to production
    • Basically helps prevent configuration errors by removing as much as possible the human aspect
  • All builds should contain a database script (under version control) that creates/restores the database  from scratch
    • This way each database change is linked to a version under version control and errors can be linked to each build
    • Also this makes finding bugs a lot easier as they are easier to reproduce

Unitiy IOC

Feb 11th

Posted by dan in Best practice

2 comments

Basically, with Unity, I ended up writing something like this (simplified version) :

IUnityContainer container = new UnityContainer();

container.RegisterType<IRiskRepository, RiskRepository>();

string conn = ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;

container.Configure<InjectedMembers>().ConfigureInjectionFor<RiskRepository>(new InjectionConstructor(conn));

UnityControllerFactory factory = new UnityControllerFactory(container);

ControllerBuilder.Current.SetControllerFactory(factory);

Unity turned out to work very well. I was able to save a lot of lines of code and it is greatly improving the testability of the dynamic modules I am using on the mock project architecture. Also, it was easy to set up. Its a good alternative to the other more popular IOC.