I have (or will have) one DAL containing my data access methods of our ERP system.
Business-wise there are contexts that will use this DAL. Examples are: Barcode applications, custom sales picking applications,purchase order applications.
I am thinking instead of creating one DLL for my business layer to break it down to these major areas, thus making them communicate with DAL in-dependably. This will help reduce bloat on my finished apps
This is my first question, the second is that Data Acess objects that are common between the Business layers should they reside in a separate project in order to be accessible by all BLs?
Lastly , these data access objects are uselul to DAL also since many methods return lists of these objects to either Business Layer or directly to Presentation (not common but will happen). Should they refer to the same common class that has the DAO’s?
I think that the answer to your second question is fairly clear; the DAL should have its own project.
As to the first, it really depends on how much commonality there is vetween the different application needs. You also need to consider whether spilitting into several BLL DLLs will increase the complexity for maintenance of the Business logic.
I would urge caution on your last item of accessing the DAL as well as the BLL from the same UI. This means that you could have dependancy on both. It may be better to put simple methods into the BLL which just call the DAL functionality and return the answer so that everything goes from the UI to the BLL to the DAL.
Of course, with all of these things, you need to think about which answers will suit your applications and development methodology the best.