DRY has become a big buzzword these days that puts emphasis on reusability. While there are some advantages to reuse, I'm going to look at the downside; having DRY applications which are rigid crack over time due to the lack of Moisture.
What is Moisture? It is the syntactic sugar that makes procedural languages like JScript, VBScript, FoxPro and T-SQL powerful and fast. Unless you've been hiding in a cave, you have started migrating from an ORM (such as NHibernate) to more future-proof constructs like Stored Procedures or DataSets.
In the past, the only downside to Stored Procedures was that Refactoring them took a lot of effort. However, JetBrains has recently announced ReProcedural to which lets you refactor code written in VBScript, Microsoft JScript or T-SQL
Once you have moved all of your business logic to stored procedures, just plan on having an average of 4 stored procedures per table (for insert, update, delete and select). In a medium sized system with 50 tables, it's completely acceptable to have an upwards of 200 stored procedures or more. At this point, your team should have enough T-SQL work to justify having a DBA letting you focus on increasing system Moisture with procedural programming
Finally, you will want to rewrite any aspects (AOP) as table triggers. For non-DBAs out there, triggers are essentially AOP for databases. For instance, if you wanted to implement logging your pointcut will either be your Stored Procedure or your Trigger.
Remember the basics of Moisture: the more OO code you can migrate to a procedural language, the better. While you can do procedural programming in C# or Java, it's not something enforceable as there is nothing stopping some n00b developer from creating an Interface or an Abstract Class. As a general rule, all methods should be public and static
April Fools!!! :-)
No comments:
Post a Comment