Anti-Patterns To Avoid In Entity Framework N-Tier Applications

Anti-Patterns To Avoid In Entity Framework N-Tier Applications
"Anti-Pattern #2: Assuming Static Requirements
Speaking of changes to the system, sometimes you design around an assumption that requirements will remain static, but there are two cases where changing requirements have an especially significant impact. One comes from treating the client as trusted, and the other occurs when the mid-tier service assumes the client will be implemented using a particular technology."
Pattern and decoupling assumes the interface is static and will never change, when overall requirement keeps changing, the database schema could be totally invalid at some point of game, thus the store proc and interfaces are all invalid. that's where you lost all your decoupling benefit and feel more pain about adapting to the new design.