I can't help feeling it can't be doing much if there was only one class for business and data layers.
I'd expect to see three layers processing > Business objects > Data Access
Two layers Processing > Data
If there is no complexity in the business objects or data access then I'd think about whether having 3 layers adds anything over 2.
In small systems where I'm using ADO I have used one class per table. This defines the type and contains the CRUD methods.
Thank you for your reply.
The service receives info from a socket and save certain data to the database and adds messages to MSMQ. Would the processing layer be the same as the service layer? Am I right to say I can call my Data access layer from inside this layer?
Your application in it's entirety would be referred to as the service layer in most terminology I've come across.
If you have just one table you're writing to then I see zero advantage to separating concerns.
By processing I mean "main" or main plus the odd class that does some stuff other than the data. So maybe you have a class for the sockets stuff eg. That's listening and when it's event is triggered by some data, reads it, whacks it into a type defined in the table class and calls a method of the table object to write the record.
Maybe you need some logic splits the data up into fields - that could well go into your table class.
You should only be adding layers where they give some benefit. Turning something that splits a string into 3 fields and writes it to a table into 3 layers is a bad idea.
Thank you for the reply
Ok there are multiple tables and multiple stored procedures involved in this whole process. So I think that would justify using the Data Access Layer. The Business Objects will be used for other services and projects so reusability is the motivation for this. I also think by using layers improves maintenance and debugging. I am just not sure if you call the DAL from the processing layer or are there something extra I need. Or should all the DAL and BAL classes be inside the web service and not in separate projects?
Isn't the time to decide you're definitely going to gain a benefit from separate layers after you decide what each of them will do?
What is your DAL going to do?
What is your BAL going to do?
Whilst it's often seemed like a good idea to share code across projects I usually find good reasons why it's not great in practice.
The batch load does different validation than the online data entry.
Couple of other points.
If you're using an ORM or something to generate code then sharing it isn't really much of an advantage.
When I use one class per table I've often used a stored procedure per method for CRUD.