Last post Oct 28, 2011 07:31 AM by neon2
May 10, 2011 09:58 AM|castlehills|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.
May 10, 2011 10:14 AM|HeartattacK|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?
May 10, 2011 07:35 PM|castlehills|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.
May 10, 2011 07:57 PM|HeartattacK|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)
If all an abstraction does is delegate to another abstraction, then consider whether or not you really need it.
May 11, 2011 07:16 AM|castlehills|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?
May 11, 2011 07:45 AM|HeartattacK|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?
May 13, 2011 06:18 AM|Kamiran|LINK
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..
May 15, 2011 11:26 PM|castlehills|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.
May 16, 2011 05:24 AM|HeartattacK|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).
Oct 26, 2011 12:56 PM|castlehills|LINK
In the recent MSDN magazine, Dino says Repository is part of DAL.
Oct 26, 2011 01:04 PM|HeartattacK|LINK
Maybe the implementation is...the declaration should reside on the client of the "DAL". Otherwise, your source code dependency will be in the same direction as the control flow, leading to tight coupling.
Oct 28, 2011 07:31 AM|neon2|LINK
"HeartattacK" is right
Why u do need a seperate DAL , when u can control DB operation by Repository Layer and one thing tier means physical seperation not logical.