Oh; that's nice to say because I thought both concepts mean the same. What is the difference?
Julen
Posts
-
Three tier architecture, database access layer pattern [modified] -
Three tier architecture, database access layer pattern [modified]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!
-
Three tier architecture, database access layer pattern [modified]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!
-
Three tier architecture, database access layer pattern [modified]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?
-
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.