Group: Forum Members
Posts: 2,
Visits: 25
|
As far as I have read so far (including the SF help and the SF forums), it looks like the SF BO acts as both the data mapping layer, and the data transfer object between the mapping layer and the client. I find the concept of having a separate business entity and business entity collection acting as the DTO along with a business object / manager / service (call it what you will) working against a DAL to be more preferable over a single object performing all these responsibilities.
What is the naming convention you folks, current SF users, prefer for your BOs? e.g. Customer or CustomerBO or Customers? Doesn't it feel weird to call moveNext on a Customer object? How about treating a "Customers" (plural) as if it were a single object, and accesing its public property called Name? This confusion seems to stem from the fact that there is a hidden dataset within each SF BO.
These are some of the concerns that I thought I would share with the current user base and the SF developers. I mean no offense in any way. I am highly tempted to purchase a .NET application framework rather than spend time building it. However, I need to feel comfortable and confident about all aspects of the system.
|