Say you had 3 layers...UI, UI Objects and Data Access Objects...in an overall application.
How would you pass data between the layers?
Woka
Printable View
Say you had 3 layers...UI, UI Objects and Data Access Objects...in an overall application.
How would you pass data between the layers?
Woka
I'm sure everyone does this differently but for me I usually use my biz layer, my objects. I generally have my forms and what not use objects representing the data which also handle any data access internally or call something else to handle the actual db transactions. I'm not a real fan of the db, I prefer objects so my way may be a little different. In the next version of VS there will be this thing called ObjectSpaces which allows you to map your classes directly to the database. I'm rather looking forward to it, currently I use an abstract class which provides all the db work for me dynamically.
i would pass a dataset between the data layer and the business layer, and abstract object between business layer and UI.
Someone please let me know if I'm doing it wrong!
Pretty much done it all the ways you have mentioned.
The cleanest approach that I liked best was putting objects in the middle. These objects would expose properties to the UI layer. The UI would know NOTHING about the database, not even a column name. To me, that is the cleanest approach, but sometimes not always the fastest approach.
I have 2 classes in my UI Objects project.
Users and User.
The Data access layer passes a DataSet to my UI Object, where the data is stripped out and placed in my 2 objects above.
The UI then only sees my 2 custom classes.
However, I have been told this is wrong and that I should be passing the DataSet to the UI and making it "strongly typed" (something I don't know much about yet)
Is this what u r both doing?
Woka
Here's a small VB6 project.
I have 3 layers.
The data is passed back from the data access layer by means of a byte array, which is then extracted in the objects layer and collections and varibles set.
Is this what you do, but replacing the byte array with a dataset?
Woka
I don't much like passing the dataset around. It's great if you are in a pinch and need to get someting done fast because it takes the least amount of code but it also provides the least control or if you end up parsing it then it eats you end up writing code for that anyway. Datasets, evenly strongly typed, aren't ideal for adding special validation to or related functionality and they seem bloated to be using just to pass data around. Although they are quick and easy and sometimes I use them. I also use XML and serialization to pass things around sometimes. I usually do this if I want more flexiblity since I can have anything write XML and pass it in, but to save code for parsing I have known objects just serialize to XML and pass that. Of course this is just one man's opinions and I'm currently trying to find more ways to use the dataset object to speed up coding. I saw your examples in the other thread I just didn't respond because I thought my way didn't represent the 'norm'.
so you would crete your OWN objects, User, Users etc in the objects tier and that manually write code to handle them rather than using a strongly typed dataset?
This is the way I would go, but have been told that datasets are better...the problem is that I am in no position to enter into a debate as I know very little about the subject. However, I know that passing a disconnected recordset up through layers to the UI and letting the UI directly use it is bad programming :D
Woka
Yes that is what I do or I use an abstract/base class that I made that handles all the database work and just inherit from it. It uses attributes or reflection to build the queries and does the work for me. Its the same concept as Object Relational Mapping which is pretty much what a dataset does too, although the Dataset is better at it then I am. Than any changes to the database just need to be reflected in the Object Mapping, the UI doesn't actually know the data just the object.
I have read that passing a Dataset up through layers isn't as bad as the samething was before but I still don't like it. Here is some info on mdsn: http://msdn.microsoft.com/library/de...tml/BOAGag.asp and a little more:
http://www.ftponline.com/wss/2002_07...efault_pf.aspx the last one (just a pdf version of the first one): http://www.mssql.org/Uploaded_Files/BizObj.pdf
Have a question then. I have a DataTier, BusinessTier and a User Interface. I pass an ADODB.Recordset to the BusinessTier. The businessTier then converts it to a collection and I pass the collection to the User Interface. It all works fine. However, I have to keep track of the cursor. i.e If I move from one record to the next one, I need to increase a variable by one or viseversa if I am moving backwords.
Is this bad programming. It would seem to me that a recordset would do all this mundain stuff for you???
Second, for some reason I can pass the recordset from data tier to Business Tier. but when I try and pass it from business to UI it errors out??
Could you explain it better about the SpaceObjects? I dont like dbs much tooQuote:
Originally posted by Edneeis
I'm sure everyone does this differently but for me I usually use my biz layer, my objects. I generally have my forms and what not use objects representing the data which also handle any data access internally or call something else to handle the actual db transactions. I'm not a real fan of the db, I prefer objects so my way may be a little different. In the next version of VS there will be this thing called ObjectSpaces which allows you to map your classes directly to the database. I'm rather looking forward to it, currently I use an abstract class which provides all the db work for me dynamically.
I agree with Edneeis's first post.
I value bulletproof code over speed anyday especially where confidential data may be involved. Speed only becomes an issue when the database queries are either complex or numerous.
I'm no expert on DB's but encapsulation is worth its weight in gold.
I actually use my own objects as well, and generally not the dataset. In my testing, using a datareader to populate your objects is way faster than filling a dataset (up to a very large number of records that you wouldn't return anyway).
I also have my object being populated on an application server and then serialized back to the client, so the data access is all done from one machine.
Of course there is the rare exception where I use a dataset and pass it back to the client (usually for a complex search that uses 1 or two fields from 10 different objects and it doesn't make sense to instantiate all the individual objects).
Also, all the DB access is done in the business class, so the UI has no idea about the database.
1stly DataSets are .NET, not VB 6 :(
The original question is HOW do you pass the data?
Using a fax badger? Hmmmmmm
I have 7 tiers splattered across different servers and client machines.
I currently use property bags, and fixed length UDTs to pass the data between the tiers...what other methods are there to pass this data?
Woka
Hi All
Though I've viewed this thread a bit late I found it very interesting. Hwever, I would like to know how the DB concurrency is maintained, in all the cases mentioned.
I mean the if the data is retrieved, a object populated passed to UI layer is just fine. But what if another user does the same.
I would like to know this for .NET (currently I'm on C#) or VB (previous experience).
That's retrieval. If you're talking about updating the database, then that's through SPs... which means the db handles it.Quote:
Originally Posted by cutamacious
Btw, I like the Entity model too. The entities handle the datasets, the app sees nothing of it.