I'm working on a project with a system that holds data and I'm thinking about using a data access approach to get data to hand it off to my components on the presentation side of things. I'm thinking of this as an N-tier architecture. Here's my thought:
Presentation layer (WebForms and User Controls)
\/Data access layer (this is where my question is)
\/Business objects (a C# class for each entity in the system)
\/Existing APIs to get data from database (MS SQL-driven)
In my DAL, I want to use a particular API mechanism from the system to get the business objects so I can pass them to my presentation components. I am aware of the repository pattern where I create various utility repository classes to "get a bunch of the X business objects". E.g. say I have a business object called Article, I could have an ArticleRepository and my "Article listing page" would call that repository and get me a collection of Article. This is nice, but might be overkill at the DAL for me. Is there a name of doing something else like just having a static GetAll() method on my business object? So isntead of:
var repo = new ArticleRepository();
IEnumerable<Article> articles = repo.GetAll();
I'm thinking something simple like this:
IEnumerable<Article> articles = Article.GetAll();
Where the Article class is both my business object with relevant properties and even helper methods, but also has a static GetAll() method. Is there a name for this approach? Is it a bad idea to create this slimmed down pseudo-repository?
I ask all this because simply put, I will have LOTS of repository classes to do this because I have lots of business objects, all with unique queries to get them from the system.
Don't know about the name of your architecture, but IMHO DAL should take care of persistence thus dealing directly with DB API.
From my experience, there's no excuse for thinking that some good practice is overkill :) Generic repository with EF is pretty simple to implement and will make you smile in the future.