|
I would argue that it is always correct to use DevForce for its data access capabilities while at the same developing as much of your own custom business logic. DevForce is meant to be a tool that provides the necessary infrastructure that allows you concentrate on providing your own unique custom business logic.
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.
|