2

I think I'm in the minority on this but would be curious to see other perspectives.

A lot of times I see people talk about the Data Layer like having functions like UpdateCustomer() or Summarize(). I really feel like the Data Layer should be more abstract than that. I currently use a generic Repository pattern on top of entity framework in my data layer. So I get functions like Find(int id), Update(), Save(), All(), etc. Very generic functions.

Then I make Business Logic layers that have more specific functions like Summarize() that work on the generic Data Layer. For me just isolating the data access technology is enough for the Data Layer. That's a big enough job on it's own. Why provide these seemingly query functions in your Data Layer? The business logic I write a large part of the time is inside Linq queries themselves so for me all specific queries should be in the Business Layer and not the Data Layer, but this isn't what I often see.

On top of that, because my Data Layers are not very generic, I can share them, they are DLL's, with other Business Layers (often web services) so that I can combine very different pieces of data together in a Business Layer to join queries between the 2 (since I have generic access to the underlying data) and it also helps in not having to recreate Data Layers for each separate solution. To me it's great resuabiltiy.

I'm wondering what the opposite view is on my view here. Why am I "wrong" in thinking this way and why is the other way "right"?

Improve this question
5
  • 2
    Your viewpoint seems reasonable to me, and I don't think it's in the minority.
    – Robert Harvey
    Commented Dec 3, 2015 at 22:12
  • 1
    Our Business Objects have only Insert(), Update(), Delete() with "Critera" class objects injected for the particulars. Very OO. In an ironic twist however the BOs insist on hitting the data source during instantiation. sigh. Your question comes because most don't know how to decouple the layers in an OO way. And if they do, they still screw it up.
    – radarbob
    Commented Dec 3, 2015 at 23:11
  • @radarbob every time a class that looks like a POCO hits a database on instantiation a unicorn dies. Lots of glittery magical blood at my workplace...
    – RubberDuck
    Commented Dec 4, 2015 at 2:51
  • I only add "high-level" functions like summarize() to my DAL if they benefit tremendously from an SQL implementation. Typically that's when I want the result of a count() or sum() or other aggregation function over a lot of rows. It's still up to the BLL to know that sum(money_spent) > 100 means "1 free pizza".
    – Ixrec
    Commented Dec 4, 2015 at 9:09
  • "because my Data Layers are not very generic" - you surely meant quite the opposite - ""because the Data Layers is very generic".
    – Doc Brown
    Commented Dec 4, 2015 at 9:09

2 Answers 2

Reset to default
2

It's a matter of definition of the terms Data and Business. Your perspective seems to be that the Data Layer is dealing with data generically and the Business Layer tells the Data Layer which data.

Another perspective is to consider the Data Layer as consisting of the collection/attributes of data classes and the Business Layer as consisting of the methods of data classes.

The only con I can think of with your approach is that the Business Layer can get a bit heavy.

Improve this answer
0

That's not exactly an uncommon scenario.

You can certainly implement your DAL in such a manner, but you will likely want another layer of abstraction between that and your business layer. I've seen it referred to as a Repository or Service layer in the past.

Your DAL offers very generic functions for finding, retrieving, or storing data. The Service layer acts as a provider to the business layer and gets these objects within certain contexts and parameters, which it receives from the business layer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.