Implementing business rules in another “business-tier” has been a popular tactic. How effective this is depends on a number of factors. I think some folks do this because they don’t understand stored procedures or find T-SQL too limiting. People would rather implement the rules in Visual Basic or C# in another tier. Sure, Yukon will permit you to write stored procedures in a CLR language, but for a wealth of reasons this might not be such a good idea. For one thing, the performance penalty imposed by switching to CLR can be expensive—the round trip can be more expensive than simply performing the operation in T-SQL. However, if T-SQL is bogged down because of complex math operations or logic it’s not suited for, it might make abundant sense to switch to a CLR-based function or stored procedure. They’re mostly a replacement for Extended Stored procedures.
I’m not a big fan of creating layers where you don’t need layers. Layers help move logic into specific groups that make team development easier and provide a single place to address business rules, data access interfaces and other related logic. In many cases, rules, triggers, defaults have worked fine. I’ve been told that Rules are passé—first implemented in the “old” Sybase version. While that’s true, I disagree that the usefulness of Rules has passed. I think Rules are easy to understand and the fact that they can be defined globally and attached to user-defined types is a great feature. They say that check constraints are designed to replace them—I’ll believe it when I see it. I think that if Microsoft pulled rules from SQL Server, a lot of folks would march on Redmond—and I can point them to the right building.
There are lots of other strategies to implement business rules. For example, I often suggest that developers use auto-morphing business rules in the client—those that can be easily changed by altering a database element (like an Extended Property). I think you need to implement the technology with which you’re most comfortable.
If you’re a plumber, you solve problems with pipe.
Bill
I’m not a big fan of creating layers where you don’t need layers. Layers help move logic into specific groups that make team development easier and provide a single place to address business rules, data access interfaces and other related logic. In many cases, rules, triggers, defaults have worked fine. I’ve been told that Rules are passé—first implemented in the “old” Sybase version. While that’s true, I disagree that the usefulness of Rules has passed. I think Rules are easy to understand and the fact that they can be defined globally and attached to user-defined types is a great feature. They say that check constraints are designed to replace them—I’ll believe it when I see it. I think that if Microsoft pulled rules from SQL Server, a lot of folks would march on Redmond—and I can point them to the right building.
There are lots of other strategies to implement business rules. For example, I often suggest that developers use auto-morphing business rules in the client—those that can be easily changed by altering a database element (like an Extended Property). I think you need to implement the technology with which you’re most comfortable.
If you’re a plumber, you solve problems with pipe.
Bill
Leave a comment