Geek Answers Handbook

DataTable Wrapper or How to separate an interface from business logic

I use web forms, C #, Asp.net. As we all know, in this model the user interface and business logic are often mixed. How can I separate them effectively?

An example I would like to use: I have a GridView and a DataTable (a GridView is bound to a DataTable, and a DataTable is loaded from a stored procedure).

I would like GridView (UI) and DataTable (business logic) to be separated.

Should I write a wrapper for a DataTable? Are there any practical samples that have been proven and verified that you could recommend following?

If someone with experience can shed some light, it will be awesome. And as a final note, I would like to say that ASP MVC is not an option now, so do not recommend it.

My database access level returns a DataTable. Please note that I have to use this database level as this is company policy.

+4
source share
3 answers

I recently looked at this post while at the same time sharing the same thing with our user interface layer.

You can see my progress here and here .

In my opinion, A DataTable does not represent business logic. In particular, data is transferred directly from the database. Business logic turns this data into a truly useful business object.

Thus, the first step is to disconnect the DataTable from the Business object.

You can do this by creating the objects and List<object> that make up the DataTables and Collections of DataTables, and then you can create a ListView that displays these objects. I will talk about the last steps in the links that I posted above. And the previous steps are as simple as the following:

  • Create a class that will represent your object.
  • iterate through a DataTable (or a DataSet, or, nevertheless, you retrieve the data), and drag these fields into the properties of this object (or List<T> );
  • return this list to a gridview or listview to display.

This way your ListView or Gridview will not be closely related to the method that you retrieve your data from. What happens if you decide to later retrieve data from a JSON request or XML file? Then you have to build it there.

Step 1 - Retrieving Data from the Database

There are several methods for retrieving data from a database, so I cannot go through all of them. I assume that you already know how to retrieve data from a database, and if not, there are several links . Suppose you connect to a database and use SQLDataReader to retrieve data. We will pick up there.

Class diagram

 Foo ---- id Name Description

And here is the method:

  private void FillDefault(SqlDataReader reader, Foos foo) { try { foo.id = Convert.ToInt32(reader[Foo.Properties.ID]); foo.Name = reader[Foo.Properties.NAME].ToString(); if (!string.IsNullOrEmpty( reader[Foo.Properties.DESCRIPTION].ToString())) foo.Description = reader[Foo.Properties.DESCRIPTION].ToString(); else foo.Description = string.Empty; } catch (Exception ex) { throw new Exception( string.Format("Invalid Query. Column '{0}' does not exist in SqlDataReader.", ex.Message)); } }

Once this happens, you can return the list by going through this process in a while that targets the SQLDataReader.Read() function.

After that, pretend that the returned Foo is a List. If you do this and follow the first link above, you can replace Dictionary<TKey, TValue> with List<T> and achieve the same result (with slight differences). The Properties class simply contains the column names in the database, so you have one place to change them (in case you're interested).

DataTable - Comment Based Update

You can always insert an intermediate object. In this case, I would introduce a business layer between the DataTable and the user interface, and I discussed what I would do above. But a DataTable is not a business object; This is a visual representation of the database. You cannot transfer this to the user interface level and call it deactivated. They say that you should use a DataTable, they say that you need to port this DataTable to the user interface? I can’t imagine that they did it. If you do, then you will never be weakened. You always need an intermediate object between the DataTable and the user interface layer.

+2
source

I would start by decoupling the data table directly into the trash. Create a domain level and then some type of data access level that deals with the database (ORM recommended).

Then create a service layer that provides data to the user interface. All business logic must be inside the service or the objects themselves.

0
source

Consider the possibility of implementing the MVP template (presenter presentation model). This gives you separation of logic through the presenter’s interface, which also allows you to improve unit testing capabilities. Your aspx code page is just an event connector and getter / setter properties. You can find it in MS templates and use corporate application blocks (CAB - an integral block of the application - if I'm not mistaken).
You can read more about this here: http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
But it is also preferable to switch from DataTable / DataSets to objects (POCO).

0
source

More articles:


All Articles