score:2

Accepted answer

no, that's not weird, and in fact that is very similar to how i do it.

only differences for me:

  • i use iqueryable<t> instead of ienumerable<t> (to get deferred exec)
  • i have a generic repository (repository<t>):
    • iqueryable<t> find()
    • void add(t)
    • etc etc

this way, my repositories stay clean/simple.

so your bll could be implemented like this:

public ienumerable<order> getorders(long customerid)
{
   repository<order> orderrepository = new repository<order>(); // should use di here, but i digress
   return orderrepository
             .find() // no query executed...
             .where(o => o.customerid == customerid) // still nothing...
             .tolist(); // query executed, with bl applied! cool!
}

makes the bll do the projection/work/logic. repositories just handle persistence of t, doesn't care about the actual type, or any business logic.

that's how i do it anyway.

score:0

my question would be what would you lose if you merge the current bll and the dal? - they both seem to be dealing with bridging the gap from persisted data (dbs) to objects.. seems like the simplest thing that would work. another way of looking at it would be is change localized ? e.g. if there is a change in dal layer, would that be isolated or would it ripple through into the upper layers (which is undesirable).

the bll ideally should encapsulate the rules/workflows of your domain aka domain knowledge. e.g. if certain customers are treated differently. the dal exists to transform your data from the persisted state into objects (or data structs to be consumed by higher layers) and vice versa. that's my understanding as of today...

score:1

consider that your data access layer could be providing services like:

  • create
  • update
  • delete
  • getsinglecustomer()
  • calculateuppermanagementtuesdayreport()

i wouldn't say it's terribly odd, but perhaps your dal doesn't need to provide those services, as your application doesn't require them.

having your filter/join/select in the bl, i'd prefer iqueryable<t> instead of ienumerable<t>. this means that the execution of a given statement in the bl code doesn't happen until you call single(), first(), tolist(), count(), etc, etc within the bl code.


Related Query

More Query from same tag