3

I am a beginner. I am finding it very difficult to understand one concept here.

I have been told that I should not use DataTable in UI level.

Please help me understand the concept.

Solution:

MyApp.Data
MyApp.Logic
MyApp.Web

MyApp.Web references MyApp.Logic, and MyApp.Logic references MyApp.Data.

On my application, what I am trying to do is simply bind a gridview by the tablename, which is chosen from a dropdownlist. However, there are hundreds and more tables. The purpose here is just to display data to the user (with paging).

So a class "Get_Data" on project MyApp.Data has a function:

public static DataTable Get_DataTable_By_Name(string Table_Name)
{
    //Check and santize the table name for possible SQL injection attack.
    //SELECT FROM DATABASE TABLE.
    return DataTable;
}

From MyApp.Logic, I am just passing the datatable from the MyApp.Data tier to MyApp.Web. And then the gridview is bound and everything is working here.

So what I am doing wrong here? Is it really bad to have datatable in UI level? Why is it a bad design?

Nancy
  • 147
  • 2
  • 18
  • 2
    Everything is in order. It's not best-practise to create, load **and** consume a DAL object in the UI layer. But that's not the case here. – Tim Schmelter Sep 01 '13 at 21:16
  • Google search suggests me this post: http://stackoverflow.com/questions/1613817/is-excessive-datatable-usage-bad – Nancy Sep 01 '13 at 21:19
  • 1
    However, it's probably better to use a strongly typed `IEnumerable` instead of a weakly typed `DataTable`. – Tim Schmelter Sep 01 '13 at 21:22
  • I could not understand "not best-practice to create, load, and consume a DAL object in UI layer". That's exactly shown on MSN documentations, and all of the sudden, a new rule is confusing me. – Nancy Sep 01 '13 at 21:24
  • So what is the benefit of defining CustomType? – Nancy Sep 01 '13 at 21:30
  • In a 3-layer scenario your DAL can return a datatable but you should consider creating separate classes to handle the information. So you can create a User class that holds all user information (name, login, etc) and several methods to perform CRUD operations, from these methods you should call your DAL and map he datatable returned into a User object. So when @TimSchmelter says to return IEnumerable, when calling you User.GetUsers() you return IEnumerable. This way, your data dependency is not spread into presentation layer – Gonzix Sep 01 '13 at 21:58
  • OK I got it. But still, that would involve a lot of extra work for this case when weakly typed datatable does the job with less code. – Nancy Sep 01 '13 at 22:14
  • 1
    @Nancy: yes, that's why I have said that everything is in order. But since you already use 3-layers i assume that its a larger project. Then its better to use custom types instead of DataTables which can hold only primitive types as object. – Tim Schmelter Sep 02 '13 at 05:19
  • Also, `DataTable` is a bit old-school. It would be more modern to use LINQ instead. – John Saunders Sep 03 '13 at 14:22
  • @JohnSaunders, I am a beginner and learning. It would be kind of you if you post an answer and describe the LINQ usage here. :) – Nancy Sep 03 '13 at 19:37
  • You would find it more useful to Google "LINQ". Also, ["LINQ to Entities"](http://msdn.microsoft.com/en-us/library/bb386964.aspx). – John Saunders Sep 03 '13 at 19:45

1 Answers1

4

The notion that it is bad practice for your UI to create/load/consume a datatable comes from the idea that it is preferable to split your application into layers that specialize, the most common split is to have 3 layers:

Layer 1 is a data layer responsible for communicating with the database and populating domain objects, the domain objects are typically defined in layer 2 which also holds the business logic for your application.

by domain objects i mean classes that represent real things like customer, bank account, hotel room etc. and by business logic i mean the rules that apply to domain objects during events i.e. when a hotel room is booked a confirmation is sent to the customer.

the third layer is the UI layer, to simplyfy coding this should only deal with whats in layer 2, this is where the recommendation to not use datatables in your UI comes from.

the motivation to split your application really start to make sense when your application is big, or you have multiple developers working on it, or your using unit testing. If you're in that situation then i'd try and find a friendly member of your team to explain this better, but if this is just you writing an application on your own then i wouldn't worry too much about it, write lots of code, read lots of books and this stuff will make more sense, i would recommend the craig larman book on uml and patterns.

hope this helps

Giles Morris
  • 91
  • 1