bjmarte

*bump*

No, it doesn't help, it only keeps things muddy.  The "Some can be but all shouldn't be" philosophy seems like it has room for some pretty broad interpretation. Your guideline to "weigh and trade off data-traffic with server utilization" isn't all that clear either.  Even if I thought that was the correct design criteria for where to put the business logic, you don't give any standards to measure by.

Don't get me wrong, I use and love Microsoft technology, especially .NET.  The reason I love .NET though is that it has made it easier to build well architected applications, while making it harder to write poorly architected applications.  Clr\Db integration seems like it is moving in the other direction, making it easy to put business logic in the database.  There are still a large group of Microsoft developers (sorry VB'ers) who don't fully understand proper architecture and this is a misleading gesture to them. 

Microsoft should either drop this "feature" to go work on indigo or they should do a much better job of explaining it's proper use.  Otherwise I guarantee there will be database implementations bloated with business logic.  I know people now who think it is a good idea to put business logic in stored procedures as a general practice.  The fact that clr\db integration even exists is asking for people who don't know better to write business logic in their database.

No response.  It's good to know that Microsoft doesn't understand the proper application of it's products either.  You guys are scaring me.

Sorry I'm late to the party, just found the time to start watching some of the videos this month.  One down, nine more to go.

One thing I'm very confused about regarding sql/clr integration.  How does writing business logic on the data tier fit into a three tier archetecture?  In other words, why in the world would you do this?

Thanks,
BJ