The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Using datasets in the presentation layer

Should datasets be exposed to the presentation layer or does this break n-tier design.

The arguement for datasets is that they are easier to use and can be easily binded to controls like data grids. They also have the sorting and filtering functions built in.

On the downside it seems like the business layer is supposed to be protecting the presentation layer from all knowledge of how the objects are stored. This seems like the business layer is not abstracting the data access layer like it's supposed to do.

Do strongly typed data sets solve the problem? Anyone have any thoughts on the subject?

Thanks,
Mike
Mike Send private email
Thursday, March 30, 2006
 
 
I wouldn't.
But that's just me.  ;-)
example Send private email
Thursday, March 30, 2006
 
 
Certainly a very bad method, but with ASP.NET you just dont have other choice.

BTW I'm working on a small framework to integrate ASP.NET with two-way binding (to general object) and NHibernate, and it also simplifies the life-cycle of components and pages. I haven't tested it with Master Page yet. It looks like:

      <aqd:forEach runat="server" bind-source="Users" dataVarName="user" bindItem-id="#user.ID">
        <itemTemplate>
          <div>
            Name: <input runat="server" type="text" bind-value="#user.Name"/><br/>
            Age: <input runat="server" type="text" bind-value="#user.Age"/><br/>
            Voices:

The whole process for end-user is quite simple: you initialize business objects in OnInit, then my framework will bind these objects <-> UI automatically for you, and for postback your event handlers will be invoked at proper time to modify the state (only two phases for your pages). The data binders are separated from UI controls and I already have a general binder for all non-container components using reflection. It could support legacy dataSource too. Right now I'm working on versioned object for persistence, if you're interested please let me know (PS: it will be released under BSD license)
AqD Send private email
Thursday, March 30, 2006
 
 
I started off using strongly typed datasets for my ASP.NET stuff, but I found them to be a MAJOR pain to maintain and extend. I switched to an O/R mapper, and IMHO that's the way to go. The code is much simpler. Yes, you may have to do some stuff manually when binding to grids and such (depends on which mapper you use), but there's a lot of other code you don't have to write. And you don't have to mess around with the visual dataset designers.
sloop
Thursday, March 30, 2006
 
 
If you are able to get your data in a Collection then that will bind to a control.  I have seen a large project with strongly types datasets and the problem with that is duplicated work.  When they wanted to change the database, they had to change the database itself, and the scripts the generated the database, and then also the strongly typed datasets.  I prefer to use the method that I used at another position where we used CodeSmith and generated the data layer from the database directly.  Our templates had all of the code for generating the collections and we just bound to those.
SteveM Send private email
Thursday, March 30, 2006
 
 
+1 for CodeSmith.

Also look at the generic BindingList<T> in .NET 2.0. With generics, you now bind your custom business objects directly to UI controls. 

Also look at the ObjectDataSource control. You can use CodeSmith or any other generator to create a bunch of CRUD methods, and then use ObjectDataSource and the supported controls to handle CRUD operations.

Bottom line: in 2.0, the case for datasets is even weaker than it was before because there are new alternatives.
PWills Send private email
Thursday, March 30, 2006
 
 
If you're working in .NET 2.0 you can use an ObjectDataSource to bind to.  Basically it's a custom object with various Select, Delete, Insert, and Update methods which takes and returns the object in question.  So you can still use DataSets behind the scenes but expose objects to the presentation layer.
Kyralessa Send private email
Thursday, March 30, 2006
 
 
ObjectDataSource is too limited to do anything beyond demostration. Just consider this => <%#Bind("MyObject.ChildObject")%> (no, you can't do this!)

Google it and you'll find only frustrations.
AqD Send private email
Thursday, March 30, 2006
 
 
ORM is the way to go.

I never use datasets because they aren't strongly typed. And the strongly typed one's created by VS are just junk. They are totally bloated and they are completely inflexible. I mean, 1500 lines of code for a single table with about 10 columns?!?! We have over 200 tables in our solution with most of them having way more than 10 columns. There is no way that I am going to waste a minimum of 300,000 lines of code just to get basic data access. And I believe that in .NET 1.1 the dataset classes generated were sealed so you really couldn't extend them in any way. What was the reasoning behind that?

I sat in on a presentation of NHibernate recently and it sounded fairly good. I would possibly consider it for my next big system.
Turtle Rustler
Thursday, March 30, 2006
 
 
Oh, and I recently had a Java guru tell me that Sun is adding support for DataSets in Java. I just laughed and asked "why?". He looked at me like I was clueless. Then again, maybe I am...  ;)
Turtle Rustler
Thursday, March 30, 2006
 
 
Dataset is just wrong. It's sad that Sun can't realize ORM with MVC-styled framework could actually makes coding much easier.
AqD Send private email
Friday, March 31, 2006
 
 
www.llblgenpro.com is your friend...
Matt Trinder Send private email
Friday, March 31, 2006
 
 
>> There is no way that I am going to waste a minimum of 300,000 lines of code just to get basic data access.

Do you have to pay someone for each line of code you use, or what?

You never have to even look at the designer-generated code for typed datasets!
Larry Lard Send private email
Friday, March 31, 2006
 
 
I much prefer having my own custom objects being sent to the presentation layer, but on occassion I'll use a Dataset and I only feel a little dirty when I do it.
Mark Hoffman Send private email
Friday, March 31, 2006
 
 
moronica
Friday, March 31, 2006
 
 
"Do you have to pay someone for each line of code you use, or what?"

Um... yes. Indirectly. It results in much longer build times, larger releases, and an architecture that is much harder to use and maintain. My current ORM architeture allows me to write a data class for that same 10 column table in less than 150 lines of code. 1500 vs. 150 is a pretty big difference.

And don't even get me started on usability. What could be easier to use than this:

// ----------------------------------------
// Add a new customer to the database.
Customer cust = new Customer();
cust.CustomerID.Value = "1234";
cust.FirstName.Value = "Turtle";
cust.LastName.Value = "Rustler";
cust.Process();

// Read a list of customers
List<Customer> customers = CustomerQuery.ReadByLastName("Rustler");

// Read a single customer and change their last name.
Customer cust = CustomerQuery.ReadByCustomerID("1234");
cust.LastName.Value = "Soup";
cust.Process();

// ----------------------------------------

This type of syntax just makes a lot more sense to me. The equivalent dataset syntax on the other hand is not very intuitive. Sure, DataSets are easier to use when creating drag and drop UI interfaces. But those require tons of tweaking to make them release quality so you get a lot less benefit.
Turtle Rustler
Friday, March 31, 2006
 
 
Why doesn't MS have their own OR mapper. How do they do it in their example applications.  It'd be pretty sad if their recommended solution was to use a third party OR mapper.
Vince Send private email
Monday, April 03, 2006
 
 
Hey guys, I highly differ from your opinions about datasets.
Of course, datasets are bad if you think of it as your data access layer basic object, because every query (with tons of rows and columns) and every schema (xls type metadata about the format of data) is put into memory, that sounds really bad for real life.
So we'll all agree that a data access layer based on datasets just sucks. But dataset has some other benefits that make it the perfect thing to connect your business layer and your presentation layer, because dataset is a generic datatype that might content any other scalar type organized in a definite structure, rows, columns and so, and that's exactly what you'd like to get if you're going to use an mvc approach, your views will deal with dataset models retrieving and submiting them to business layer through controllers. That will make your base classes to automatically being using the same data unit all along the tiers.
I'm personally using an easy approach (mvc and not mvc) with this, I have data access layer with some OR mapping generated classes (myGeneration & codesmith) and then business classes (which I call business façades) interfacing that DAL subsystem, and then business classes offer data to presentation as datasets, and normally this data is a partial view which is the product of aplying a lot of business rules.
So yes, for me datasets (more precisely datatables) are a good way to communicate presentation layer and business layer.
Greets.
converdb Send private email
Tuesday, April 04, 2006
 
 
"Why doesn't MS have their own OR mapper."

At a guess, the reason is that it's complicated to make an O/R mapper that covers _every_ case and is also very easy to use.  O/R mappers exist that meet the first criterion (comprehensive but complicated setup) or the second (easy setup, but not that flexible), but for an O/R mapper to fit with the Microsoft ethos, it would have to do both.
Kyralessa Send private email
Tuesday, April 04, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz