|
| | | StrataFrame Beginner
Group: Forum Members
Last Login: 01/25/2008 10:58:36 AM
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. |
| |
| | | 
StrataFrame Developer
Group: StrataFrame Developers
Last Login: Yesterday @ 7:08:30 PM
Posts: 4,811, Visits: 4,781 |
| 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. I beleive that this is a misunderstanding on your part. The framework does break these up into distinct layers and all of the logic is not in a single class. 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.
This really has no bearing on the framework and is a decision that you can make for your own application development environment. However, within our medical application (and any other application for that matter) use the naming convention of CustomersBO for the name of the class then we may rename this when dropped on a form to Customers for the specific instance. 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. I will let some of the SF developers respond to this if they choose to. However, this is how we got into the framework business ourselves. We have a need for our medical software, trying to buy a framework, then ultimately wrote our own and commercialized it. I am not going to try to sway you one way or the other....this is a decision that only you can make, but my recommendation is to create a sample application to determine if the framework will actual do what you need it to do. We have written StrataFrame to be a very extensible framework, but again, you still have some time left on your trial and I would use that time to write a small sample app to see if your needs are met. |
| |
|
|