According To Ali

I have been stuck with this issue and couldn't take it out of my head. Hence, ended up putting in some heavy hours solving it. But hopefully it is worth it. THE CONTEXT: I am implementing a MVC solution for an existing Sitecore 8.0 implementation which uses Castle Windsor for it's dependency resolver. Let's say a a tiny microsite. I had to implement a SPEAK app as per one of the requirements. Below are the 2 most important things behind why I ran into this issue in the first place: I needed to call a WebApi from my SPEAK app. 2. I decided to take MVC Area approach for my "tiny microsite" on a completely different sets of dlls For example the dlls for my "tiny microsite" are MyTinyApp.Web.dll, MyTinyApp.Business.dll whereas the main website's dlls are BigWebsite.Web.dll, BigWebsite.Business.dll etc.  WHY MVC AREA: The reason I took the MVC Area approach was to completely separate my "tiny microsite" so that I don't

I have read a bit on BDD. But none of the theory seemed appealing enough that I would be like “hai ! this is cool. Let’s do this”. Probably because I am a lazy tester or more appropriately test case writer (unit test that is J). What supposed to happen ? TDD. Write test cases first àdrive the development from there ( based on whatever model is chosen or appropriate). What actually happens ? As much as the next guy wants to throw theory and technical jargons I’m not really sure how many mid-scale project processes actually follow TDD throughout the entire development phase, let alone maintenance phase(where it’s most important) OR BDD for that matter. What I do mostly? The truth is (at least if I speak for myself) I have not followed through a proper TDD process. Yes there always exist some test cases that are written and thrown into build process so that we can use it in future. Even more sometimes we write the test cases after the feature is developed. But I

This is how I would think of an application at the very basic level: Now this works great. But one thing that is missing in this picture is Exception Handling . In many cases we pay very less attention to it and take it as "we'll cross that bridge when it'll come to that". We can get away with this as in many application as exceptions does not stop it from being in the state "is the application working" as long as we code it carefully and at the very least handling the exceptions in code blocks. This works. But we end up having try catch and if else everywhere and often with messy or no direction to what type of exception is to be handled where and how. Nonetheless, when it comes down an enhancement that depends upon different types exceptions, we will end up writing/modifying code every where, resulting in even messier code. I'm sure no one wants that. Even, in scenarios, a custom handler is not the answer either. Cause this way we will s

​ Okay so this is something I picked up from a recent developer group thingy and have been annoying my colleagues about this since then. Instead of thinking Sitecore as one project (MVC) solution why not treat it like a module/deliverable based implementation. I have created a sample solution which is here: https://bitbucket.org/ali_nahid/sckitchensync   The idea is pretty simple (Just like DDD pattern): You get a rough idea of the entire implementation like what are the  deliverable , functionalities etc etc and group them. Then just like the way you plan renderings on your page you plan bunch of different modules to implement in your solution. In my case I divided my sitecore implementation into the following modules: 1.       The core: This module contains the layouts and core renderings. In my case 1 standard layout that just defines the top level placeholders. Like header, footer, content etc. And a “_MainContent” rendering that defines the o