Calling a method in a different solution

Question

Currently I have a solution whose hierarchy looks like this.

-GUI
 -ENTITIES
 -DATA
 -BLL
  -ENTITIES
  -DATA
   -ENTITIES

1) Is that the right way to lay it out. I'm removing the DATA reference from GUI currently (just legacy code that I'm moving to the BLL)

2) Is there any way for ENTITIES to call a method from the BLL or DATA? Like in Entities.Order have Order.GetNextOrderID() that calls a method from DATA?

Answer 1

1) Is that the right way to lay it out. I'm removing the DATA reference from GUI currently (just legacy code that I'm moving to the BLL)

This is an extended subject and it is scenario dependant.

Picture a sistem with componentization, integration with other systems and protocols, native code, multiple client protocols, mobile, test, etc. There would be a lot of layers and multiple Solutions would be needed. Same principle apply for different platforms.

There are a lot of criteria you would have to consider, so the answer is: it depends.

But I guess for what you are doing it fits well.

2) Is there any way for ENTITIES to call a method from the BLL or DATA? Like in Entities.Order have Order.GetNextOrderID() that calls a method from DATA?

No, you will get cyclic dependency error. A single module would do it tho, but I wouldnt recommend it.

Also, if you are going to define validation in the entities, make sure your design will not allow for duplication in services (bll) or data. This can go out of control if you do not have a good team or pair revision etc.

The main purpose of the layers is to give it specific responsabilites. If you have well defined responsabilities to your layers you should be fine.

Answer 2

I will re-iterate my comment for question 1.

Is that the right way to lay it out.

The "right way" is project dependant.

Is there any way for ENTITIES to call a method from the BLL or DATA? Like in Entities.Order have Order.GetNextOrderID() that calls a method from DATA?

Not with your current setup.. you'll get a circular dependency. You've become confused between a more DDD-approach (which is what you're going for.. nice!) and an Anaemic Domain Model where the logic sits outside of the entities.

You should choose where the bulk of your logic will sit and work from there. For the DDD approach you're asking about, the Entities project will contain 90% of your logic, and it will have a dependency on the "BLL" project for any other "services" the entities may require.

The flipside for the Anaemic Domain Model is that you have a service in the BLL that loads everything it needs and does all of the operations in the actual service. Your entities then become nothing more than POCOs.

Answer 3

Well a good design would be to keep the Data layer separate from both the GUI and BLL. So that each layer can perform a single task i.e GUI should only concern about the User Interface, controls and views. Business Logic Layer should only implement the Business rules and data layer should interact with your database. For your second question all you need to do is add a reference of your Data project to Entity project. Hope it helps you.