That should be higher up than your business objects themselves. Obviously security is part of your business logic, but the use of the information (allowing pages to load, displaying certain links, etc) is mostly a UI concern, and should stay there.
An exception would be if you're using the CFLOGIN framework, or any kind of integrated framework that'll do the horrible nasty work of tracking user information across the layers of your application in a way that doesn't break encapsulation all over the place. I personally don't use the CFLOGIN framework, but that decision was greatly influenced by the fact that I already had a robust permission-based security system in place. If you're into having method level security (rather than something tied to the UI), it's definitely the way to go. cheers, barneyb ----- Original Message ----- From: Marlon Moyer <[EMAIL PROTECTED]> Date: Fri, 13 Aug 2004 18:54:05 -0500 Subject: [CFCDev] How smart should objects be? To: [EMAIL PROTECTED] I have an object (company) that contains all the pertinent information/methods for viewing/updating a company profile. Some users are only allowed to view the profile while others are given the ability to modify the information. Should the company object accept a user object that contains permissions and roles and allows actions based on it, or should I have a security object that would call the company object? I guess what I'm getting at is where do you put your security? Does it make sense to embed it into objects or does that make it too complex? Marlon -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
