Hi
Assume we create 3-tier module, which enables us to display/create/edit articles. Articles are:
• organized into categories
• before article can be published, admin has to approve it by setting Approve field of Articles DB table to true
• by setting MembersOnly field ( Articles table ) admin can also specify whether particular article can be viewed by anybody or only by registered users
• Articles table also has ExpiredDate field, which tells when will the article expire and thus no longer be published
a) At DAL layer we provide methods GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory for retrieving articles from the DB
At BLL layer we use GetArticles() overloads to call all of the above DAL methods.
What are the some of the benefits of using single overloaded method at BLL layer instead of BLL methods having one-to-one correspondence with DAL methods? Only advantage I can think of is that this way same ObjectDataSource control can call two or more of GetArticles() overloads, depending on the value of parameters, for example:
public static List<Article> GetArticles(bool publishedOnly) { if (!publishedOnly) return GetArticles(); ... }
- If you don’t also design UI layer and thus can’t be sure which methods UI programmer will prefer the most, would it be best practice for DLL layer to provide four overloads of GetArticles + GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory?
2) When designing DAL methods to retrieve data from DB, how can you in advance know/predict ( without first designing the UI ), exactly which methods (for accessing DB) we should create at the DAL layer?
Namely, in the previous example I’ve had several methods for retrieving articles based on number of parameters ( based on category they belong to, whether we only want published articles etc). Assuming I’m selling this module to third party UI developers, then there is no way to know which data access methods they would prefer the most:
a) so should I create as many data access methods as I can think of ( one for getting all articles that are already expired, one for getting all articles that are already expired, but were never published, one for getting all articles that are not published, one for getting all articles that can be view by registered users only… ) ?
b) Even if all three layer are written by myself – should I still create as many data access methods as I can think of?
thanx
EDIT:
A common way to achieve this is to use interfaces to define the behavior of the API.
a) I’m not sure I understand this. Which class should implement this interface? Perhaps DLL class? In other words, if the name of my DLL class is Article, then third party would derive class named ChildArticle from Article, where ChildArticle would also implement this interface? Or did you mean something else?
b) Anyways, as far as I understand it, providing interface ( which declares defines additional DLL methods to retrieve articles from DB ) would also require DAL class to already have appropriate methods defined, which would be called by methods declared in the interface?
To your point, I believe it is a good idea to prefer fewer coarse-grained methods in the BLL to cover all the functionality required by an entire business operation
I’m not familiar with this term, but you’re prob suggesting that we should prefer overloaded GetArticles() over GetAllArticles, GetArticlesByCategory, GetPublishedArticles and GetPublishedArticlesByCategory?
A) The design of an API is strictly related to what it is meant to achieve and by whom it will be used. In practice, this means that you should know the target audience of your API, and give them only what they need to get the job done.
Unless I personally interview the people that would buy my product, I can generally guess which methods they would find useful, but within that space, there are still any number of possible methods I could define. Thus, how should I know whether they would also find use for, say, GetArticles() overload which retrieves articles that already expired?!
On the other side it is perfectly fine to have many smaller data-centric methods in the DAL to work with specific pieces of data.
If not DLL, should DAL have as many data access methods as I can come up with ( for particular target audience of course )?
SECOND EDIT:
A few extensibility points can be built into the API to obtain a certain degree of flexibility. A common way to achieve this is to use interfaces to define the behavior of the API. This will allow consumers to replace or extend the pieces of the built-in functionality by providing custom implementations.
Assume I create a BLL layer and then provide some additional interfaces, which consumers could implement to extend BLL’s build-in functionality. But for consumers to be able to implement these interfaces, they will need to have access to BLL’s source code, right? But what if I don’t want consumers to view BLL’s source code?
Interfaces should exist between layers. More specifically, classes should interact with classes from other layers exclusively through interfaces
a) So even DAL’s built-in functionality should be exposed through interfaces? But why? Namely, if we’d use abstract class instead of interfaces, then this class could already implement some utility functions common to all provider classes that inherit from this abstract class?! On the other hand, if DAL uses interfaces instead, then utility functions common to all providers will have to be implemented once for each provider, which could mean a lot of redundant coding?!
b) Anyways, I don’t quite see the benefits ( except when we provide interfaces with which consumers could extend the basic functionality ) in having classes from different layers interacting through interfaces?
For added clarity, instead of overloading methods to work with different parameters, I believe it is better to have one method that accepts a single parameter. This parameter would be an object containing all the data for the method to work with. Some of that data could be required, some could be optional and would influence the effect of the operation.
If I know UI will extensively make use Object Data Source controls, should I still prefer BLL to define a single method (this method having as parameter an object with all the data for the method to work with) instead of method overloads?
cheers mate