In a three tier architecturer app, you will see UI, Business and Data Access layers. If we introduce the Repository layer into this three tier architecturer, where the Repository layer will go? Will it go to the BLL (which has the domain layer) or to the
Data Access layer?
Or when a repository layer is introduced, will it be a 4 tier application and repository layer will sit between the BLL and DAL?
I'm going with the last answer which is the architecture becomes a 4 tier.
The concept of a repository is usually part of Domain Driven Design. DDD has concepts of layers, but they're significantly unlike layers in n-tier architecture. [And those layers deal with component functionality rather than implementation details.] DDD
and n-tier are different paradigms. Before you go about implementing a repository on top of your DAL, think about why you're doing so. Are you doing it because you actually need an in memory representation of your data that you can't get from your DAL (in
that case, what's your DAL doing exactly?)? Do you really need that extra layer of indirection? Will there be any significant benefits in adding an abstraction that will undoubtedly increase complexity? Are you falling into a pit that you're trying to avoid?
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
Marked as answer by HeartattacK on May 21, 2011 08:42 AM
The front end application had a Linq To Sql DAL when the project was stared. There was a repository layer on top of the DAL. This layer had aggregates like orders, customer etc.... After a while the Linq To Sql DAL is replaced by a WCF service. The repository
layer now aggregates objects from the WCF layer. When I made the diagram to show the architecture, I created layers as blocks on top of each other (similar to the web architecture template that comes with the Visual Studio).
I liked the approach of presenting the layers as onion layers (ref to Scott Millet). But there was a disagrement of what the people are familier with.
There should be a clear decision made from the get go wether you want DDD or n-tier. They have fundamental differences. Do your entities have public setters? If so, chances are you're already violating aggregate root integrity. n-tier focuses on data centric
aspects whereas DDD focuses on behavioural ones.
Anyway, a DAL is supposed to be a Data Access Layer. Where that data comes from (db, flat file, web service) should not be a factor. You could have an abstraction of the DAL (for example, expose interfaces) and switch in different implementations of the
DAL (from db or web service). You don't need a further abstraction of a repository on top of the DAL. In most n-tier scenarios, a repository is the DAL and vice versa. Otherwise, most of your "layers" would have methods that look like this:
Doesn't a domain designed with ddd principle and with other UI, App Service layers lead (or the end result) to a n-tier application? I don't mean they are seperated physically as tiers but as layers?
They don't result in layers necessarily. n-tier has a consistent representation of data flowing from one layer to the next. DDD puts emphasis on aggregates and entities - they carry out most operations. n-tier promotes "entity" classes that hold mostly data.
DDD promotes "entity" classes that encapsulate data, expose behaviour and communicate using value objects. In n-tier, it's typical to see a database table have the same structure of a class and that class is used to communicate data between "layers". In DDD,
what the UI gets could be vastly different from what's in the database. The domain entity class that handles stuff could have a significantly different structure as well. Most get this wrong and hence questions like yours arise - should I put a repository
there between my service and DAL? DDD is more than just repositories and renaming classes to match real things. It's fundamentally different to n-tier. Would your fourth repository layer be doing anything that your DAL shouldn't be doing in your n-tier scenario?
In that case, why add that abstraction? Is there a tangible benefit?
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
Marked as answer by HeartattacK on May 21, 2011 08:42 AM
After going through the presentations of some architectures from different writers, I can say that Repository can be in BLL or DAL. It exposes a domain or model. It can sit between a UI and a service layer also.
If you're using a repository, there's no point in having a separate DAL. They're purpose is pretty much the same. Consider having the repository interface in what you call your BLL and have the implementation in the DAL. The client (BLL) owns the interface
and the implementation (DAL) referenes the client (BLL).
"If I can see further than anyone else, it is only because I am standing on the shoulders of giants."blog: www.heartysoft.com twitter: @ashic
castlehills
Member
259 Points
171 Posts
Is Repository Layer is DAL?
May 10, 2011 01:58 PM|LINK
In a three tier architecturer app, you will see UI, Business and Data Access layers. If we introduce the Repository layer into this three tier architecturer, where the Repository layer will go? Will it go to the BLL (which has the domain layer) or to the Data Access layer?
Or when a repository layer is introduced, will it be a 4 tier application and repository layer will sit between the BLL and DAL?
I'm going with the last answer which is the architecture becomes a 4 tier.
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: Is Repository Layer is DAL?
May 10, 2011 02:14 PM|LINK
The concept of a repository is usually part of Domain Driven Design. DDD has concepts of layers, but they're significantly unlike layers in n-tier architecture. [And those layers deal with component functionality rather than implementation details.] DDD and n-tier are different paradigms. Before you go about implementing a repository on top of your DAL, think about why you're doing so. Are you doing it because you actually need an in memory representation of your data that you can't get from your DAL (in that case, what's your DAL doing exactly?)? Do you really need that extra layer of indirection? Will there be any significant benefits in adding an abstraction that will undoubtedly increase complexity? Are you falling into a pit that you're trying to avoid?
blog: www.heartysoft.com
twitter: @ashic
castlehills
Member
259 Points
171 Posts
Re: Is Repository Layer is DAL?
May 10, 2011 11:35 PM|LINK
Thanks for that insight.
The front end application had a Linq To Sql DAL when the project was stared. There was a repository layer on top of the DAL. This layer had aggregates like orders, customer etc.... After a while the Linq To Sql DAL is replaced by a WCF service. The repository layer now aggregates objects from the WCF layer. When I made the diagram to show the architecture, I created layers as blocks on top of each other (similar to the web architecture template that comes with the Visual Studio).
I liked the approach of presenting the layers as onion layers (ref to Scott Millet). But there was a disagrement of what the people are familier with.
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: Is Repository Layer is DAL?
May 10, 2011 11:57 PM|LINK
There should be a clear decision made from the get go wether you want DDD or n-tier. They have fundamental differences. Do your entities have public setters? If so, chances are you're already violating aggregate root integrity. n-tier focuses on data centric aspects whereas DDD focuses on behavioural ones.
Anyway, a DAL is supposed to be a Data Access Layer. Where that data comes from (db, flat file, web service) should not be a factor. You could have an abstraction of the DAL (for example, expose interfaces) and switch in different implementations of the DAL (from db or web service). You don't need a further abstraction of a repository on top of the DAL. In most n-tier scenarios, a repository is the DAL and vice versa. Otherwise, most of your "layers" would have methods that look like this:
void DoSomething(int foo)
{
_lowerLayerInstance.DoSomething(foo);
}
If all an abstraction does is delegate to another abstraction, then consider whether or not you really need it.
blog: www.heartysoft.com
twitter: @ashic
castlehills
Member
259 Points
171 Posts
Re: Is Repository Layer is DAL?
May 11, 2011 11:16 AM|LINK
Doesn't a domain designed with ddd principle and with other UI, App Service layers lead (or the end result) to a n-tier application? I don't mean they are seperated physically as tiers but as layers?
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: Is Repository Layer is DAL?
May 11, 2011 11:45 AM|LINK
They don't result in layers necessarily. n-tier has a consistent representation of data flowing from one layer to the next. DDD puts emphasis on aggregates and entities - they carry out most operations. n-tier promotes "entity" classes that hold mostly data. DDD promotes "entity" classes that encapsulate data, expose behaviour and communicate using value objects. In n-tier, it's typical to see a database table have the same structure of a class and that class is used to communicate data between "layers". In DDD, what the UI gets could be vastly different from what's in the database. The domain entity class that handles stuff could have a significantly different structure as well. Most get this wrong and hence questions like yours arise - should I put a repository there between my service and DAL? DDD is more than just repositories and renaming classes to match real things. It's fundamentally different to n-tier. Would your fourth repository layer be doing anything that your DAL shouldn't be doing in your n-tier scenario? In that case, why add that abstraction? Is there a tangible benefit?
blog: www.heartysoft.com
twitter: @ashic
Kamiran
Member
225 Points
196 Posts
Re: Is Repository Layer is DAL?
May 13, 2011 10:18 AM|LINK
Hi castlehills..
I am not a professinal, but the way i create the n-tier apps, i have the repository in the DAL.
the connection between the UI and the DAL is throgh the BLL.
I hope this will help..
castlehills
Member
259 Points
171 Posts
Re: Is Repository Layer is DAL?
May 16, 2011 03:26 AM|LINK
After going through the presentations of some architectures from different writers, I can say that Repository can be in BLL or DAL. It exposes a domain or model. It can sit between a UI and a service layer also.
HeartattacK
All-Star
55262 Points
5917 Posts
Moderator
MVP
Re: Is Repository Layer is DAL?
May 16, 2011 09:24 AM|LINK
If you're using a repository, there's no point in having a separate DAL. They're purpose is pretty much the same. Consider having the repository interface in what you call your BLL and have the implementation in the DAL. The client (BLL) owns the interface and the implementation (DAL) referenes the client (BLL).
blog: www.heartysoft.com
twitter: @ashic
castlehills
Member
259 Points
171 Posts
Re: Is Repository Layer is DAL?
Oct 26, 2011 04:56 PM|LINK
In the recent MSDN magazine, Dino says Repository is part of DAL.