Question A beginner's concerns about Windows Forms & Security

[rajthampi]

Hi guys

I am a seasoned Oracle developer, forced to start developing Windows forms against MS SQL server as my firm is planning to implement Microsoft Dynamics AX suite. I know bit of how to use the Vistual Studio IDE and how to hook up the tables using textboxes and by using DataSets

My friends in the field of .Net development are trying to discourage me from using DataSets, instead asking me to fill the textbox columns using SQL within the scripting part, that looks cumbersome as most of the applications what we will port from Oracle ERP, the tables associated are having more than 100 columns and each form may have a minimum of 30-40 columns displaying various information.
I request the experts to point me towards the concerns raised by my peers.


Thanks in advance!

regards,

raj

 

[jmcilhinney]

fill the textbox columns using SQL within the scripting part

I don't really know what that means but I can only think of two possibilities and they're both pretty much irrelevant.

1. You are using the Data Source Wizard to generate a typed DataSet and your friends are recommending that you use an untyped DataSet with inline SQL. They're not helping you in that case. There's no net advantage to using an untyped DataSet over a typed DataSet. It does mean that you have more obvious fine control over some of the details but, more often than not, you don't need that fine control. Using a typed DataSet means writing far less code for the majority of scenarios and that's a big plus. For situations where you need finer control, you simply don't accept the defaults and make some manual changes, which far too many people don't even seem to realise is possible. In the very rare situations where a typed DataSet just won't cut, simply use an untyped DataSet for those situations specifically. There's no rule that you can't mix and match where it's advantageous to do so.

2. You have your SQL code in your VB app and they are recommending that you use stored procedures in the database. They're not helping you in that case. There are certainly positive aspects to putting your SQL code in the database, but there are negatives too. Regardless, you can use a typed or untyped DataSet either way. Both data adapters and table adapters (which are just a wrapper for a data adapter anyway) can use inline SQL or stored procedures to retrieve and save data.

From my perspective, I'm an application developer so I consider the SQL code to be part of the application, so that's where it goes. People who view the world in a more database-centric way might argue the opposite. There may also be a case for a combined approach, e.g. I put my queries in the application and triggers in the database.

As for DataSets, if you're going to use one then I would recommend a typed DataSet. There is a misconception in some parts that using a typed DataSet means putting all your data access code in the forms themselves. It doesn't. You can create a robust, enterprise-grade data access layer that has no knowledge of a UI with a typed DataSet. Personally, I use Entity Framework almost exclusively and would recommend it to others. You do need a decent working knowledge of LINQ already though, otherwise creating anything but the simplest of queries can be very difficult.

 

[rajthampi]

Thank you very much

Dear jmcilhinney

Thank you very much for your valued inputs. I was/am working with Oracle centric development from last 15+ years and had the epiphany when I tried to create a simple master detail data entry form using some sample HR schema that I stripped from Oracle database!
I do agree, there are different and biased approaches towards and Yes, I must choose based on the requirements.

Thanks once again!

regards,

raj