4

After reading this , I still have a question :

I use this code to query the db :

c# :

new BLL().GetPersonById(1)

BLL :

public Person GetPersonById(int id)
{
  return new DAL ().GetPersonById(1);
}

DAL :

public Person  GetPersonById(int id)
{
   // goto db and create instance of Person and fill its data...
}

However , am I doing it wrong ,

Should my DAL return DataTable instead ? ( so the BLL will create Person .... ?)

DAL :

public DataTable  GetPersonById(int id)
{
   // goto db ...
}

Thank you.

Edit :

the Person object is defined in BE dll ( business entity).

Community
  • 1
  • 1
Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • Return whatever you need in your BLL. Does your DAL know `Person` at all? – Tim Schmelter Nov 07 '12 at 08:02
  • @TimSchmelter hi Tim , however , I want to know if referencing my dal to BE ( entities) is a bad thing , since BLL already reference it... – Royi Namir Nov 07 '12 at 08:03
  • @TimSchmelter yeah it have a reference to BE.(entities) – Royi Namir Nov 07 '12 at 08:04
  • 3
    Personally, if I saw `DataTable` being used *at all* without some **very** good reasons (mainly: if the schema is completely unpredictable), then I'd say something is very wrong... `Person` all the way! But: there is no single answer here. Just opinion. – Marc Gravell Nov 07 '12 at 08:06
  • It's somewhat subjective. It depends on what you actually need and how public your class library is. Do you use it in multiple projects or just in this? Fillling a DataTable, returning it and then converting it to a `List` is expensive and redundant. So if the `Person` is a known class(or your DAL is just used in this project) you should return that. – Tim Schmelter Nov 07 '12 at 08:07
  • @MarcGravell Aamof , the schema is very unpredictable , and a result of joins and besides the DB is not normalized ( the db wasn't created by me - but by foolish people). – Royi Namir Nov 07 '12 at 08:14
  • @TimSchmelter but what if I return datatable to `BLL` and **he** creates the `Person` , this was - I save the reference from `DAL` to `BE` ? – Royi Namir Nov 07 '12 at 08:17
  • What exactly do you have in BE project? Interfaces? The Business Objects themselves? Because in that case , what do you have in the BLL? Maybe your business entities are in fact ORM entities? – MikeSW Nov 07 '12 at 08:56
  • @MikeSW I have in BE - The Business Objects themselves. the BL calls the DAL and also do some logic. – Royi Namir Nov 07 '12 at 08:59
  • So in fact the BLL is the Controller or a command handler. In my book, the business layer contains only business objects which encapsulate business logic. The app layer knows about business objects and the DAL, not neccessary directly but via interfaces, especially if you're using a DI container – MikeSW Nov 07 '12 at 09:02

2 Answers2

3

"Should my DAL return DataTable instead ? ( so the BLL will create Person .... ?)"

Not at all. Ideally DAL is supposed to deal with database and should return entity/application objects to BAL. DAL works as a abstraction for database to BLL.

And I am agree with MikeSW as he said "BLL shouldn't depend on the DAL, at most it defines some interfaces which will be implemented in the DAL."

Praveen Prajapati
  • 969
  • 1
  • 16
  • 21
  • why should the DAL reference the BE ? what is wrong for the BLL to create the Person from datatable from DAL ? – Royi Namir Nov 07 '12 at 08:43
  • 1
    There are some basic concepts we should understand to create the layers. Different layers are used for allocating the responsibilities of an application. In case of... BLL is taking Datatable from DLL....and after a while if database changes...you need to change the logic in both DLL and well as BLL..That is not so good....Otherwise just you need to change DLL only. That is just one example to why it BLL should get entity/application objects only. There are more things like Maintainability, clear workflow design, change with minimum effort and side effects etc.. – Praveen Prajapati Nov 07 '12 at 08:56
  • PraveenPrajapati + @mike can you go please to http://chat.stackoverflow.com/rooms/19201/room-for-royi-namir-and-mikesw – Royi Namir Nov 07 '12 at 09:03
2

Your DAL, well the Repository to be exact, returns Person which is a business object defined in BLL.

BLL shouldn't depend on the DAL, at most it defines some interfaces which will be implemented in the DAL. However, the app asks the DAL for stored business objects as is its responsiblity to deal with everything persistence.

And yes, the DAL depends on the BLL. THe DAL sohld return only aplication objects (business objects or view models), everything persistence access related should be hidden.

MikeSW
  • 16,140
  • 3
  • 39
  • 53
  • 1) the Person object is defined in **BE** and not in **BLL**. ( edited) – Royi Namir Nov 07 '12 at 08:11
  • @MikeSW I was under the impression that DAL should have absolutely no idea about BLL, and BLL should only know DAL's interface. However, they should both know about shared object definitions (such as *Person* in this case). Am I wrong? – neeKo Nov 07 '12 at 08:15
  • 1
    It depends on the app size. At the highest level, yes you would have a common layer containg only interfaces, then BL and DAL would implement them and none would know about each other, but it's a bit to over engineered if you actually don't need that. – MikeSW Nov 07 '12 at 08:52