Hi David,

Thanks for your reply. My response below.



<-- This might be easier once partial classes are available. Can you explain in an example how you use your one-to-one relationship? Maybe it is supported in another way?

We use one-to-one to mimic class inheritence in database. So, for each entitry class there is a corresponding data table in the database. Child classes will have their one tables, and these are linked to their parent tables by foreign keys. we use inner joins in select statements, and wither an update statement for each table, or SPs for databases that support them. We find this approach is the most natural fit between relational databases and OO programming.

<--Are you thinking of something that would generate the rules as attributes and then the UI controls would read these attributes from the business layer with reflection?

I think there should be role based security in the framework based on a GenericPrincipal. This is really a separate issue from enforcing busines rules.
>

Actually, what we did is we populate field-level security data in server-side business components on the server. We put this information in extended properties in the resulting datasets. Each user will have his own modified schema and this will be teporarily cached on the server for later use. UI controls will use this information accordingly. There are some other security considerations. If the user does'nt have the right to view certain fields, we simply remove the information completely on the server before sending the data to the client. We also ignore updates to read-only or hidden fields (on the server components). This simply because we may be exposing this information to third party clients (as web services for instance).



<--I couldn't find anything on property provider. Are you talking about the PropertyDescriptor class?
>

They are actually Property Extenders and they are classes that implement the IExtenderProvider interface. Example: ToolTip, ErrorProvider

Regards