You can also build your own business objects that do not inherit from DataTable and DataRow,  For an example of this, see the advanced tutorial on "Binding to Non-Persistable Business Objects".

 

However, if you do do intend to persist your custom business objects to a back-end database, I would argue that you should use DevForce for this.  Otherwise, you will have two different persistence mechanisms.

 

I understand your complaint about the extra 110 or so devforce data row properties and methods (which just adds to the confusion and makes the overall business class a mess), but that's no reason to throw the baby out with the bathwater.  If you use regions to hide this code (which you probably don't want to look at anyway),  I don't the final concrete classes confusing at all.  You should be looking at your own code anyway, not the code that is automatically generated.

 

I believe that the best way to provide your own "Entity Navigation" is by extending and enhancing our existing mechanisms.  There isn't a lot we have provided in terms of security (but see our tutorials on authentication and authorization), so I think there is a lot of value you could add in terms of security.

 

My question is: Is it ever ok to use devForce primarily for data access and use your own business layer to perform business logic. In this scenario, aggregation is used to store a reference to the devForce Entity inside our own custom business object. This means that our custom business object can control "Entity Navigation" at a more granular level based on our security model AND  we end up with a business entity without all the extra 110 or so devforce data row properties and methods (which just adds to the confusion and makes the overall business class a mess).

 

Thanks