I know that <asp:SqlDataSource> is fast, but is it a good practice to use this. The sqldatasource is right there in the aspx page and the SQL for sqldatasource is also right there.
Does that not break the 3 tier model, as normally we call a database layer and we have all the SQL's there.
In one of the code in saw the following. I don't know if it is a good practice to do something like this.
<asp:DropDownList ID="CountryDropDownList" runat="server" DataSourceID="SqlDataSource2" DataTextField="PickListLabel" DataValueField="PickListValue" OnDataBound="hidePanel">
</asp:DropDownList>
<asp:SqlDataSource ID="SqlDataSource2" runat="server" ConnectionString="<%$ ConnectionStrings:webrepos %>"
SelectCommand="SELECT [PickListLabel], [PicklistValue] FROM [PickList_Values] WHERE (([ObjectName] = @.ObjectName) AND ([FieldName] = @.FieldName)) ORDER BY [AbbrCode]">
<SelectParameters>
<asp:Parameter DefaultValue="Account" Name="ObjectName" Type="String" />
<asp:Parameter DefaultValue="Country__c" Name="FieldName" Type="String" />
</SelectParameters>
</asp:SqlDataSource>
If your application doesn't require a business layer, then you could probably use a SqlDataSource safely with stored procedures. However, if you plan on moving to a tiered architecture, then I'd move to an ObjectDataSource which will allow you full flexibility on how you want to access your data.
|||
sahajMarg:
Does that not break the 3 tier model
My current personal site uses the SqlDataSource. I wanted to get something up quickly. I built the site in a few evenings (including the rudimentary backend). If I had decided not to "break the 3 tier model" and opted for custom business objects, it would have taken me a fair bit longer. The SqlDataSource was the perfect choice, given the circumstances. Like Ed suggests, I use stored procedures. But with only a dozen or so pages in the site, I didn't need to. The 3 Tier model is inappropriate in my case.
Having said that, I am toying with the idea of rebuilding it over Christmas with LINQ.
I use both. I tend to use SqlDatasources for filling simple things like dropdowns, gridviews, etc.
But when I need to do complex logic, or non-trivial updates (updating multiple tables that requires transaction support) then I'll skip the SqlDatasource and call my DAL methods directly.
I'm not a big fan of the 3 Tier model to begin with, but it does have its place. It's just that place isn't where I sit usually, but I've been on projects where it was appropriate. That said, I'm also not a huge fan of stored procedures either. In most of my recent work, security is a niceity. There is no real privacy issues, or critically sensitive data involved, but changes come quick. Request, to implementation, to roll out is measured in days, and the simplicity of having inlined SQL where it can all be versioned as a singular unit far out weighs the benefits on my current projects.
If the project holds customer data, credit card information, medical records, or other such sensitive data then I'd probably recommend stored procedures, and possibly a 3 tier approach. If the project involved multiple programmers, developers, and designers then I might recommend a 3 tier approach especially if one or more of them can be focused on the backend data storage.
|||I'm not keen on fiddling around in the back of a SqlDataSource. I don't know why - it's just a "thing" with me. Where I can't drag, drop, configure and forget, I'll switch to using my helper methods instead.
|||
mike thanks for your reply. now it perfectly makes sense.
