VB.NET and N-Tier, opinions and thoughts.

Hi all,
  we are currently beginning on the path of .NET, previously we have built N-Tier applications using the method of mapping database tables each to a single object and a collection object. By using these objects we built the UI either in VB 6 or ASP.
  All our objects are programmed in VB6 as ActiveX dll projects.
 Our single object would provide functions to load, save, delete etc a single record from a table, it would also have properties that matched to fields in the table. Our collection objects would retreive a collection of single objects using functions.
 We never used databinding on the front-ends, basically all the validation and manipulation of data was done through the objects, and it used recordsets, commands etc to do data updates etc.
 I hope I have made myself clear.
 Now here is the question, from looking at VB.NET, I am now wondering if this is the right way for developing new applications in .NET. I am sure we will not use a lot of the new power of ADO.NET and VB.NET, if we don't use databinding controls such as the datagrid.
 See my previous experience in old VB was not to touch databinding, as you lost a lot of control especially when validating data.
 What are people doing in the real working world with .NET, having objects return datasets and using them? Or building them in wrappers?

 Any thoughts and opinions, would be appreciated.


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


Databinding is the way to go with the new .Net architexture.  you still have a little bit of a control issue since you have to make changes to the under lying object, but databinding in .Net is much faster than it ever use to be and it allows for data to change while not affecting the display object until you refresh.

In a nutshell, one of the more exciting features about .Net is its use of databinding.
Hi Jetforce,

I announce you that you entered in a brand new world.

In the real world of .NET N-TIER application, microsof suggest to us to return data object as Dataset form if its possible. There have more then one reasons, a lot of new functionnalities was implemented in the dataset, XML integration, DataRelation, Dataview, multiple table support, disconnected data, transaction ... The dataset really replace at my own opinion the wrapper and it offer stability ,flexibilty and a lot of power.  

My last VB.NET apps use wrapper and with my new skill i think i have made an error!

For the validation, a lots of control events was implemented to permit to you to validate data, it's pretty different of previous version and databinding will help you a lots for saving coding time if you use it correctly. Don't be effraid to use it!

I suggest to you to buy MCAD/MCSD self-placed training kit(Microsoft press) it's a good and cheap way (240 US$ www.amazon.com) to learn good practices in four pretty good books(Developping windows applicatoin with VB.NET and Visual C#, Developping web applicatoin with VB.NET and Visual C#.Net, XML Services and server component, Analysing requirements and defining .NET solution Architechtures.).

I hope that will help you!  
We have an n-tier app (Windows Forms, web services and SQL server) which uses databinding and datasets.   Its been running in a production environment for 1.5 years with over 500 users with good reviews.  

However we are moving away from datasets toward our own data-bindable objects because 1) the XML serialization of  a dataset is very inefficient and 2) using custom objects provides a more Object-oriented programming interface for our front-end developers.   I would recommend this approach over an approach where you "wrap" a custom object around a DataSet.  

I agree with the other posts regarding databinding - they've made it a lot more usable with the control events and the ErrorProvider object.  And the notion of being able to operate in a "disconnected" mode on the client and then post multiple changes to the database is very powerful.

To summarize:
1.  A dataset based architecture can work but you may encounter performance issues if you're using Web Services and/or XML serialization.  We had to limit our result sets to less than 50 rows (and implement nextpage/prev page) in order to keep the response time under 2 seconds.
2.  If you're going to use your own objects instead of DataSets, I recommend going "all the way" and making your objects bindable and serializable.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

Hi jetforce:
> . I am sure we will not use a lot of the new power of ADO.NET and VB.NET, if
> we don't use databinding controls such as the datagrid.

I partly disagree with the other posters, and have a similar approach to yours:
I do not trust databinding, and after trying it out with datagrids in .NET, I still distrust it.

Good news is that .NET has some nifty nice new features and improvements over VB6 that make the non-binding approach quite attractive.

For example: The Tag property is not a String but an Object.
At first I was dissapointed that the DataField property was removed in .NET. I use this property in VB6 to traverse through the controls and update them with the value of the current record.
In .NET, the Tag property can be used for this purpose AND any other purpose you would want to use it for. You can create a class, store an instance of this class in the Tag property and then use the different values in any of the control's events.

A better example is the combo. The comboitems once again are objects, not strings. This means that when you build a (not bound) combo, and add items to it, you can actually store a complete DataRow in it, or an instance of your own class.
In the class definition, override the ToString function to return the one value you would like displayed when a comboitem gets selected. Cool!


Intersting approach Dabas...

I may look into that for quick and easy programs instead of messing around with Databinding.  
David H.H.LeeCommented:
I'm not good in give you advices related to your problems(afraid give you wrong directions). But, I believe this article will guide you from top to bottom about N-Tier design problems In .NET architecture design. I'm sure you'll get clear explanations from Microsoft's article.
jetforceAuthor Commented:
Thanks for all the replies,
  is there any good examples on the web, so I can see the pros & cons.


David H.H.LeeCommented:
jetforce ,
Here's the sample application web using 3 tier design pattern
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.