Three tier architecture, database access layer pattern [modified]
-
Hi, I am designing an architecture in .NET framework. I use the Three tier model to design my application but I have a concern about how is the way to properly model the access to database layer. I have separate DLL for each layer. In my business layer I want to access the database, for example to add new registry in a way that the members are not passed each one in a parameter but all in a single object. For example:
namespace myapp.bussines_layer
{
class Point
{
int x;
int y;MyDatabase db = new MyDatabase();
//I want this...
void InsertInDatabase()
{
db.NewRowInDB(this);
}//... instead of this
void InsertInDatabase()
{
db.NewRowInDB(this.x, this.y);
}
}
}The thing is that this way I have circular dependency because Point knows MyDatabase; and MyDatabase has to know Point in order to recognize Point as an parameter in the function. Does my idea fit correctly in the good practices and designs to access databases? Is better design to pass all the parameters as native types (even when the amount os parameter is high)?? I would be very grateful if anyone could help me and/or give me references to good design patterns with the connection between business and database layers. Thank you very much in advance. Julen.
Julen wrote:
The thing is that this way I have circular dependency because Point knows MyDatabase; and MyDatabase has to know Point in order to recognize Point as an parameter in the function.
Point is a predefined type; it is declared externally of both DLL's. You can do the same thing for your own classes, to avoid circular references.
Julen wrote:
I would be very grateful if anyone could help me and/or give me references to good design patterns with the connection between business and database layers.
The dOOdads[^] architecture was a nice example. It's deprecated by now, but it's clean and readable code. Fastest way to dive into that code is to use the myGeneration application to generate a small testapplication that contains them dOOdads.
I are troll :)
-
Julen wrote:
The thing is that this way I have circular dependency because Point knows MyDatabase; and MyDatabase has to know Point in order to recognize Point as an parameter in the function.
Point is a predefined type; it is declared externally of both DLL's. You can do the same thing for your own classes, to avoid circular references.
Julen wrote:
I would be very grateful if anyone could help me and/or give me references to good design patterns with the connection between business and database layers.
The dOOdads[^] architecture was a nice example. It's deprecated by now, but it's clean and readable code. Fastest way to dive into that code is to use the myGeneration application to generate a small testapplication that contains them dOOdads.
I are troll :)
Eddy Vluggen wrote:
Point is a predefined type; it is declared externally of both DLL's. You can do the same thing for your own classes, to avoid circular references.
In this case Point is just an example; my class is one of my own that has at least 10 members. If I include this class in both DLL, would'n I be breaking the separation between the business and data layer?
-
Eddy Vluggen wrote:
Point is a predefined type; it is declared externally of both DLL's. You can do the same thing for your own classes, to avoid circular references.
In this case Point is just an example; my class is one of my own that has at least 10 members. If I include this class in both DLL, would'n I be breaking the separation between the business and data layer?
Create a separate DLL for
OwnClass, and reference it from both assemblies. The separation is one of responsibilities, not of classes; you're going to pass data from one DLL to another (or, from one layer to another) - and you'll need some common ground for them to talk to each other. In pseudocode;class Person { string Name; }
class DALPerson: Person
{
public DALPerson(string connectionString)
{
Name = // load from database
}
}class BLPerson: DALPerson
{
public override ToString()
{
return "High Lord " + Name;
}
}We have met the enemy, and he is us :)
-
Hi, I am designing an architecture in .NET framework. I use the Three tier model to design my application but I have a concern about how is the way to properly model the access to database layer. I have separate DLL for each layer. In my business layer I want to access the database, for example to add new registry in a way that the members are not passed each one in a parameter but all in a single object. For example:
namespace myapp.bussines_layer
{
class Point
{
int x;
int y;MyDatabase db = new MyDatabase();
//I want this...
void InsertInDatabase()
{
db.NewRowInDB(this);
}//... instead of this
void InsertInDatabase()
{
db.NewRowInDB(this.x, this.y);
}
}
}The thing is that this way I have circular dependency because Point knows MyDatabase; and MyDatabase has to know Point in order to recognize Point as an parameter in the function. Does my idea fit correctly in the good practices and designs to access databases? Is better design to pass all the parameters as native types (even when the amount os parameter is high)?? I would be very grateful if anyone could help me and/or give me references to good design patterns with the connection between business and database layers. Thank you very much in advance. Julen.
Julen wrote:
I use the tree tier model
It's "three-tier", as in the number 3, not "tree tier".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008modified on Sunday, June 21, 2009 11:48 PM
-
Julen wrote:
I use the tree tier model
It's "three-tier", as in the number 3, not "tree tier".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008modified on Sunday, June 21, 2009 11:48 PM
Dave Kreskowiak wrote:
It's "three-tier", as in the number 3, not "tree tier".
Sorry for the spelling. :-O I don't dislike creating a separate DLL to come to a common ground between layers. So, if I have three tier architecture; will I have 5 DLL? Three for the layers themself; and two for the common grounds? Presentation layer -- Common ground 1 -- Bussiness layer -- Common ground 2 -- Data Layer Could recommend me an article, reference, matter on this issue? :) Thanks!
-
Dave Kreskowiak wrote:
It's "three-tier", as in the number 3, not "tree tier".
Sorry for the spelling. :-O I don't dislike creating a separate DLL to come to a common ground between layers. So, if I have three tier architecture; will I have 5 DLL? Three for the layers themself; and two for the common grounds? Presentation layer -- Common ground 1 -- Bussiness layer -- Common ground 2 -- Data Layer Could recommend me an article, reference, matter on this issue? :) Thanks!
Create a Common library for Data Transfer objects and share it among all layers. So this would be (Data Transfer Objects) (Data Transfer Objects) Data Layer -----------------------> Business Layer ------------------------> UI Layer
-
Create a Common library for Data Transfer objects and share it among all layers. So this would be (Data Transfer Objects) (Data Transfer Objects) Data Layer -----------------------> Business Layer ------------------------> UI Layer
Shukla Rahul wrote:
Create a Common library for Data Transfer objects and share it among all layers. So this would be (Data Transfer Objects) (Data Transfer Objects) Data Layer -----------------------> Business Layer ------------------------> UI Layer
To create those Data Transfer Objects, is there a pattern or standard design to create them? Also, regarding the picture; do you mean with the arrows that the data access layer has a reference to business layer instead of reverse? Thanks!
-
Create a separate DLL for
OwnClass, and reference it from both assemblies. The separation is one of responsibilities, not of classes; you're going to pass data from one DLL to another (or, from one layer to another) - and you'll need some common ground for them to talk to each other. In pseudocode;class Person { string Name; }
class DALPerson: Person
{
public DALPerson(string connectionString)
{
Name = // load from database
}
}class BLPerson: DALPerson
{
public override ToString()
{
return "High Lord " + Name;
}
}We have met the enemy, and he is us :)
its very simple ;P ;P
-
Hi, I am designing an architecture in .NET framework. I use the Three tier model to design my application but I have a concern about how is the way to properly model the access to database layer. I have separate DLL for each layer. In my business layer I want to access the database, for example to add new registry in a way that the members are not passed each one in a parameter but all in a single object. For example:
namespace myapp.bussines_layer
{
class Point
{
int x;
int y;MyDatabase db = new MyDatabase();
//I want this...
void InsertInDatabase()
{
db.NewRowInDB(this);
}//... instead of this
void InsertInDatabase()
{
db.NewRowInDB(this.x, this.y);
}
}
}The thing is that this way I have circular dependency because Point knows MyDatabase; and MyDatabase has to know Point in order to recognize Point as an parameter in the function. Does my idea fit correctly in the good practices and designs to access databases? Is better design to pass all the parameters as native types (even when the amount os parameter is high)?? I would be very grateful if anyone could help me and/or give me references to good design patterns with the connection between business and database layers. Thank you very much in advance. Julen.
This sounds like a serious case of entanglement. Why should Point know about MyDatabase and why should MyDatabase know about Point? What you might want to look at instead, is using interfaces to control the way things interact, and then code against the interface.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Shukla Rahul wrote:
Create a Common library for Data Transfer objects and share it among all layers. So this would be (Data Transfer Objects) (Data Transfer Objects) Data Layer -----------------------> Business Layer ------------------------> UI Layer
To create those Data Transfer Objects, is there a pattern or standard design to create them? Also, regarding the picture; do you mean with the arrows that the data access layer has a reference to business layer instead of reverse? Thanks!
You can create a project class library project which holds such classes. Provide the reference of this project in all layers. Sorry, the arrow shows the flow of the data objects not the reference. Reference would be as follows Data Access Layer - Ref of common Business Layer - Ref of Data Access Layer and Ref of Common UI - Ref of Business Layer & ref of Common Download sample project from here. -Rahul Shukla
-
Eddy Vluggen wrote:
Point is a predefined type; it is declared externally of both DLL's. You can do the same thing for your own classes, to avoid circular references.
In this case Point is just an example; my class is one of my own that has at least 10 members. If I include this class in both DLL, would'n I be breaking the separation between the business and data layer?
Julen wrote:
would'n I be breaking the separation between the business and data layer?
Not necessarily. As mentioned by others, the class could be external to both layers, or it could be defined in the lowest layer that uses it (probably the business layer). And layers aren't necessarily tiers; don't confuse the two concepts.
-
Julen wrote:
would'n I be breaking the separation between the business and data layer?
Not necessarily. As mentioned by others, the class could be external to both layers, or it could be defined in the lowest layer that uses it (probably the business layer). And layers aren't necessarily tiers; don't confuse the two concepts.
-
its very simple ;P ;P
-
Oh; that's nice to say because I thought both concepts mean the same. What is the difference?