Learning

[Mike]

Hi, noob here so apologies in advance for any misconceptions but I downloaded the telerik demo and samples materials to a Win 8 with Visual Studio 2013 Professional installed in November 2014.  I've read/worked through the first half of the "UI for ASP.Net Ajax" pdf step by step tutorial as well as referenced/tried my hand at opening the CS solutions provided.  However, I'm not getting the sense this is the most productive strategy.  Yes, the pdf provides orientation but much of the specifics are -- I presume -- out of date for my setup.  Similarly the example solutions could imho use a "readme" page in the main directory detailing how to use them (including their age, the updates VS will require, how their file structure relates to the pdf etc).

My first question then is whether a better learning strategy or materials can be suggested.  (Fwiw I'd be willing to pay someone a moderate fee to be an answer resource that can speed my learning curve.) 

Secondly I have some database experience and wasted too much time researching MVC with its requisite EF/ORM "kludge" -- instead I want to normalize and tune a database then write stored procedures to connect with webform components (please advise of security or performance issues possibly resulting as appropriate).

Thanks in advance   

[Marin Bratanov]

Hi Mike,

Our controls are standard controls for WebForms built on top of the MS AJAX library (i.e., they offer rich client-side API and functionality that can let you reduce postbacks) and as such, rely on the general experience and knowledge developers have in the field. We do not offer training resources per se, but if you need to accomplish a certain task, you can browser through the control's demos and documentation in order to see whether the feature you seek is available built-in, and examine the API that can let you tweak it or create it:

• http://demos.telerik.com/aspnet-ajax/.
• http://www.telerik.com/help/aspnet-ajax/introduction.html.

The PDF Courseware is, indeed, outdated, and I would recommend going through the Overview and Getting Started articles in the documentation to get a general idea what each control offers so you can evaluate which one would fulfill the task you have at hand.

Considering the feature set and rich API our controls offer the learning curve for our controls can, indeed, be steep, but we offer demos and documentation that showcase their features so you can use that as reference during development. If you are stuck with something you can also ask us, even trial packages give you access to the forums and our support ticketing system.

Thus, while we do not offer training courses or creating custom solutions on demand, we may be able to point you in the right direction.

On accessing databases - this is not something our controls do themselves. They are user interface controls and providing the data operations is up to the developer (e.g., creating an SqlDataSOurce control with the appropriate Select, Update, Delete commands). In terms of data binding, our controls are not different than the standard controls (even though they offer many more events and API) and require standard data sources (e.g., IEnumerable or IQueriable collections, DataTables, Lists, etc.), so they can work with virtually any data source you can provide.

It is a general approach in WebForms to directly work with the data sources through controls like SqlDataSource or with custom code in the code-behind (e.g., calling stored procedures or extracting tables). It seems this is what you need, even though this is often cited as a drawback for the platform. Thus, security and performance are the developer's task and you must make sure to validate data and user inputs on the server.

I hope this covers your questions.


Regards,

Marin Bratanov
Telerik

 

 

[Mike]

Thanks, your reply has helped considerably with "orienting" myself.  One question I do have still though is the nature of the interaction between webforms and datasources.  As you mention this is less a telerik than an ASP.Net issue, however, having previously "learned" a great deal of the MVC "process" (with GET, POST, etc distinctions) I can see clear security barriers there between front end and data.  I assume similar barriers are built into webform components already -- or are there additional measures I need to concern myself with?  

Specifically it seems so easy to link a datasource up to a webform my concern is that the "connection" can both be easily found (say by view source the webform page) and then "hit" via sql code sent by http to the same "web api" destination by a rogue agent.  Feel free to direct me to whatever link might explain the security measures involved but if there is something in the webform itself that authenticates the message to interact with the database (ie so the database rejects other inquiries) then that may be all I need to know at this point.

[Marin Bratanov]

Hello Mike,

Built-in data source control in WebForms like the SqlDataSource control do not render anything on the client (you can easily confirm this by inspecting a simple page) and what they do is to perform the query defined by the developer on the server, get the data collection on the server and pass it to the control that requests it. You may find the following resource a good starting point in researching the matter:

• http://forums.asp.net/t/1127939.aspx?How+secure+is+using+a+sqldatasource+.
• http://devproconnections.com/aspnet/sqldatasource-safe.
• http://security.stackexchange.com/questions/68243/asp-net-sqldatasource-injection-risk.

If you do not create and expose WebAPI or other services in your application, our controls will not, so this is a generic matter of handling the security of your application. You may find these articles useful to start with securing your project:

• https://luxsci.com/blog/secure-web-pages-and-web-forms-what-you-need-to-know.html.
• http://msdn.microsoft.com/en-us/magazine/hh708755.aspx.
• http://msdn.microsoft.com/en-us/magazine/dn201748.aspx.

I would also like to note that nothing of this is specific to, or caused by our controls.

Regards,

Marin Bratanov
Telerik