New Posts New Posts RSS Feed: DevForce as Data Access Vs. Business Layer
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

DevForce as Data Access Vs. Business Layer
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
jozza View Drop Down
Newbie
Newbie


Joined: 11-Jul-2007
Posts: 25 		Post Options Post Options   Quote jozza Quote  Post ReplyReply Direct Link To This Post Topic: DevForce as Data Access Vs. Business Layer
    Posted: 30-Jul-2007 at 12:19am
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


Edited by jozza - 30-Jul-2007 at 12:21am
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post Posted: 31-Jul-2007 at 9:26am
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.
 


Edited by davidklitzke - 31-Jul-2007 at 9:28am
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down