<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.technet.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx</link><description>Nowadays there is a lot of pressure on the middle tier of the three tier stack from both the database and the smart client. If technologies such as Yukon allow all the code to run in the databases is the business tier of logic required? Whilst the actual</description><dc:language>en-GB</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx#172474</link><pubDate>Sun, 04 Jul 2004 00:19:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:172474</guid><dc:creator>Todd B.</dc:creator><description>Great story! Thanks for the laugh. </description></item><item><title>re: Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx#172782</link><pubDate>Sun, 04 Jul 2004 20:16:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:172782</guid><dc:creator>Tom</dc:creator><description>LOL! That is one of the funniest things I've read in long time.  </description></item><item><title>re: Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx#175232</link><pubDate>Wed, 07 Jul 2004 20:37:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:175232</guid><dc:creator>Benjy</dc:creator><description>Nice one. Some people might argue that all this proves is the need for Business Rules validation and not a business tier and will proceed to hardcode rule checking in the tier or all in a single layer in the database. For example, they may store the rules in the DB and just call them from CLR stored procs.&lt;br&gt;&lt;br&gt;I think its important for people to understand that layers need to be logically separate to enable easier maintenance and flexibility for change and that the ability to put a ton of stuff in the DB doesnt mean you should. </description></item><item><title>re: Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx#178337</link><pubDate>Fri, 09 Jul 2004 21:51:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:178337</guid><dc:creator>Steven Kelly, CTO, MetaCase</dc:creator><description>Thanks Michael, that one made my day! &lt;br&gt;&lt;br&gt;In addition to the business rules, it also shows why anything longer than a few digits should always have a checksum digit... And why one should never, never print numbers like that for people to enter by hand, then print for other people enter by hand, then print...</description></item><item><title>re: Business Rules</title><link>http://blogs.technet.com/michael_platt/archive/2004/07/03/172422.aspx#182860</link><pubDate>Wed, 14 Jul 2004 18:01:00 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:182860</guid><dc:creator>Michael Platt</dc:creator><description>Benjy&lt;br&gt;Totally agree with you about putting stuff in the DB. Placement is something that should always be carefully considered&lt;br&gt;&lt;br&gt;Steven&lt;br&gt;Excellent point, all too often we forget the simple solutions and rely on technology</description></item></channel></rss>