Last week I published a post entitled Opinion Time: Should Developers ALWAYS Build an API?. I got quite a bit of useful feedback on that post, and so I decided that I needed to publish a followup post so that I could parse and interpret all the different opinions you lovely readers gave. I was expected something of a heated fight, or at least a good match, but it turned out to be a slaughter. One side clearly and convincingly... Read more >
There's been some talk in my office lately about the practicality of always building API (Application Programming Interfaces) backends for our apps. Some of my teammates argue that it ensures portability, that we can move to newer technologies more readily. Others agree, but say the primary reason is to provide a layer of abstraction between the code and the data (since enough abstractions can solve many problems). I personally have a much more basic problem. I'm at a crossroads, and... Read more >
My team regularly writes ASP.NET Web API projects which have multiple consumers, and oftentimes we also write at least one of said consumers. To accomplish this, we often invoke a project layout and architecture that doesn't seem terribly obvious to newcomers to my group. I hope to better explain myself as to why this project organization works in this post (so I can just say, "Hey, new guy, lookie here!" and point them at this post.) Sample... Read more >
I'm doing some heavy refactoring on a project that I've recently joined but that has been underway for months. The code is a mishmash of different styles and an uncertain architecture, so my task up to this point has been to make it more consistent, testable, and readable. One of the issues I was tasked with was improving the data access layer. The system was using a pattern known as Repository for its data access layer, and the individual Repositories... Read more >
