SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 69
  1. #26
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Cool, I was fairly certain one should not use Response.Write() for the reasons outlined above, but it was a bit shocking to see no confirm why.

    We will expain the rules once we agree on them. At the current rate that puts us sometime in 2018. By which time we will have .NET 33.33 which will actually type for us developer types.

  2. #27
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    30. Do not cache a database connection in Application or Session objects
    Doing so will interfere with the ability of the runtime environment to maintain connections in a pool for reuse. It will effectly be locked to your session/application, quickly exhausting pool slots. In fact this it leads to 31:

    31. You should open database connections late and close them early.
    If you do extensive work between 2 database accesses, you should also consider closing the connection and re-opening it. However, this is not advisable if the to accesses are to be enrolled in the same transaction. Closing a connection effectively returns it to the pool. Opening a connection aquires a connection from the pool.

    32. Do not use impersonation for database access.
    You may be tempted to use impersonation, and to access the database with the user credentials obtained from the user of the page. This way you could theoretically leverage the security mechanisms of the database server to guard against unauthorized access to data. However, this will defeat the database connection pooling (as each user will require his/hers own specialized connection), and it *will* affect the scalability of your application.
    /mouse

  3. #28
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    33. Thy shalt use CssClass instead of individual display properties.
    Multiple controls expose properties like BackgroundColor, Width etc. Using these are the equivalent of using Width=xx attributes in html (instead of style="widthx"). It is better to just set the CssClass property to a css class name, and define the display attributes in an css. Some controls may have multiple "style" properties. These will generally expose display properties. Same rule goes here. If you are using ASP.NET 2.0 themes/skins this becomes all the more important.
    /mouse

  4. #29
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    34. (version 2+ only) For databinding use the ObjectDataSource control; limit/avoid use of the SqlDataSource control
    SqlDataSource is ok for simple sites (where 3+ tier architecture is not needed) and is actually perfect for prototyping, as it allows you to mock up pages that integrates with data really fast.

    However, SqlDataSource promotes a 2-tier architecture. You will end up missing a layer where you can enforce e.g. access restrictions, where you can absorb changes in the underlying model etc.

    Using ObjectDataSource will also free the page designer from concerns about the underlying data representation. While the page designer and the developer may be the same person, you'll often find that you yourself are in different "modes" when tweaking the user interface and designing/coding the business logic.

    To leverage the ObjectDataSource you will typically
    1) design/implement classes representing entities of your model
    2) design business logic classes which expose methods to create, read, update, delete entities and to execute business actions (cancelling an order may involve manipulation multiple entities).

    If you design the business logic classes so that they have a public default constructor (no parameters!), they can be leveraged immediately by the ObjectDataSource control. This means that the business logic class must obtain connection properties itself. The connection strings in web.config are ideal for this, i.e. the business logic class discovers the actual database connection string using a well-known name (like "OrderConnectionString").
    /mouse

  5. #30
    SitePoint Addict Sojan80's Avatar
    Join Date
    May 2002
    Location
    Central WI, US
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Yes, Why can't we?

    Quote Originally Posted by Dangermouse
    Can we get explanations with the rules
    I have to agree with Dangermouse here, in that we (the new and less experienced) could definitely benefit from some more detailed explanations and examples of these so called Best Practices.

    I've wondered why it always is that these "Best Practices" are so enured in the negatives? Thall shalt not this...

    Is there some rule against saying something like Thall shall do it this way and illustrate how it should be properly done from a more positive stance and then give the "But if you don't, be prepared for the worst..." rather than focusing so much on the negative first?

  6. #31
    SitePoint Addict Sojan80's Avatar
    Join Date
    May 2002
    Location
    Central WI, US
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99
    28) Thou shalt not use Server Side Includes (<!-- #INCLUDE -->). Thou shalt use user controls or master pages.
    Okay my turn. Any particular reason why you say that?
    1. First you guys say "Thall shalt not use user controls...." and now the above rule says we should. Hello? Am I the only one who sees a Contradiction here? Could someone please clarify a little or at least put some qualifiers on when we should and shouldn't use user controls in favcr of a Master page?
    2. I find this rule completely confusing considering I am reading a Beginning ASP.NET book put out by Microsoft Press where it states that the use of <!--#INCLUDE --> is not only perfectly acceptable, but the PREFERRED METHOD of doing this for the confines of the book so now our Best Practices are contradicting one another again. This would be a great place for some examples and explanations.
    3. Also, all the tutroials and examples/tutorials I have seen regarding setting up/using/designing Master Pages have been confusing to say the least so here again is where more explanation and good solid examples would be supremely useful.

  7. #32
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Benjymouse
    33. Thy shalt use CssClass instead of individual display properties.
    Multiple controls expose properties like BackgroundColor, Width etc. Using these are the equivalent of using Width=xx attributes in html (instead of style="widthx"). It is better to just set the CssClass property to a css class name, and define the display attributes in an css. Some controls may have multiple "style" properties. These will generally expose display properties. Same rule goes here. If you are using ASP.NET 2.0 themes/skins this becomes all the more important.
    while i totally agree, MS for some odd reason puts default styles on a good deal of its controls and will override your class styles unless you ! important by those default attribute defined in your css class or create your own version of controls like the calendar control and override the defaults (i.e this.ForeColor = Color.Empty) . The font-colo/ForeColor attribute of a alot of controls are pre-set, like validators. another issue is that they often output tables with no summary attribute. =(.

    but this is defintely a good practice as you abstract styles from your presentation layer, enabling you to make global changes to the whole website, quicker, uniform, and more accurate. Good job.

  8. #33
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is a collabarative effort. Some of the "best practices" reflect individual experiences and/or preferences. Like a wiki anybody is free to contribute. Given that, you should regard these "best practices" as suggestions. They are open for debate. I myself have chimed in on a few of them.

    Actually I disagree with the "Thou shalt only use user controls when it is required on more than one page". I find that user controls offer a great way to separate concerns. IMHO there are many valid reasons to use usercontrols beyond the simple cross-page reuse:

    1) if an area of the page has a complicated UI logic which integrates several elements, but at the same time have few references to other elements/areas. In this case I find that seperating the inter-control UI logic into a usercontrol improves readibility and maintainability.

    2) usercontrols also defines pagelet cache boundries. If the output of the usercontrol is a) expensive to generate, b) cacheable and c) the page itself is less cacheable, the performance gain from a usercontrol can be enormous.

    3) if I want my page to have a special "mode" where part of the page is obscured by e.g. a temporary wizard/view, I'll often seperate this temporary wizard/view out into a usercontrol. True, I could just define the wizard/view in a panel which would be visible only when I wanted the temporary mode. But by using a usercontrol I can add/remove the extra control dynamically, thus avoiding viewstate/controlstate pressure from the extra functionality. Often I'll have multiple alternative views seperated out in usercontrols.

    4) I may want to have a "pluggable" architecture, e.g. different "viewers" for different product classes on an online shopping site. A pizza should come with the option to customize the toppings, while the coke should have only the "size" option. I may realize that I cannot tell in advance exactly which and how many product classes I'll need viewers for. Hence, I want an architecture where I can add a new product class simply by adding a new viewer usercontrol.

    On the <!--#INCLUDE -->, I find it generally undesired in ASP.NET applications. I have yet to see a good example of a problem solved with SSI which is not solved better using one of the higher level techniques. But that's just my opinion.
    /mouse

  9. #34
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sojan80
    Is there some rule against saying something like Thall shall do it this way and illustrate how it should be properly done from a more positive stance and then give the "But if you don't, be prepared for the worst..." rather than focusing so much on the negative first?
    Wow, looking back, that one hurt. But you are oh so right. Somehow it's easier to make rules for what not to do. Like "thou shall not kill". I hope that it is because there's still infinitely many more ways to do things right than it is to do them wrong?

    Can we have more of these: If xxxxxx is what you are set out to do, then yyyyyy?
    /mouse

  10. #35
    _ silver trophy ses5909's Avatar
    Join Date
    Jul 2003
    Location
    NoVa
    Posts
    5,466
    Mentioned
    1 Post(s)
    Tagged
    1 Thread(s)
    I think the "Thou shalt not" was just done in fun. It wasn't meant to infer that you must absolutely do it this way or you are wrong.

    Sara

  11. #36
    SitePoint Addict Sojan80's Avatar
    Join Date
    May 2002
    Location
    Central WI, US
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Oh I see...

    Quote Originally Posted by ses5909
    I think the "Thou shalt not" was just done in fun. It wasn't meant to infer that you must absolutely do it this way or you are wrong.

    As I am still sort of fairly new to programming as a whole, I thought we were pretty much dealing with absolutes in a lot of this stuff. My apologies...

  12. #37
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I must agree, that without an explanation of the underlying reasoning, it's easy to take the statements as absolutes. You simply have no way to validate whether your particular problem is covered by the reasoning or not.

    I encourage all posters to include a few line of discussion/reasoning/explanation. The do/do nots should be explained by why/why nots.
    /mouse

  13. #38
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Explanations are good. Here are mine, reprinted for convenience:

    2. Thou shalt not use exceptions to manage program flow.
    Throwing an exception is a very expensive operation--basically the most expensive thing short of calling external resources. Think of an exception as making the computer beep twice and pause for two seconds, then think if you actually want to use one in that place.

    3. Thou shalt wrap calls to external resources, such as configuration values or session variables in strongly typed properties.
    The idea here is to facade things like the Session object away. For example, add a property to your base page class such as the below:

    Code:
    protected string UserName
    {
    	get 
    	{
    		string ret=Session["username"];
    		if (ret==null)
    			ret=string.Empty;
    		return ret;
    	}
      	set 
    	{
    		Session["username"]=value;
    	}
    }
    This means that your application no longer has to worry about the specifics of the username storage, it just pulls the property. So when you decide that it is better to store it in a cookie, all you need to do is change the property. Moreover, when one is storing complex types, it centralizes all the casting.

    4. Thou shalt not use DataSets in web applications.
    We had a nice little debate on this subject on page one. In general, one does not want to use data sets even if they make things nice and easy. The main drawback is that architectually, using a dataset means the front end application is quite aware of the back-end database and business logic tends to bleed into the presentation layer. One ends up with a 2.5 tier solution oftentimes. The other major disadvantage of a dataset is they tend to get very inefficent, especially for large datasets. Bottom line is to only use them where having an in-memory representation of the database makes sense.

    27. Thou shalt use common sense.
    I hope this transtlates . . . .

    28) Thou shalt not use Server Side Includes (<!-- #INCLUDE -->). Thou shalt use user controls or master pages.
    Best explained by Benjymouse above.

    29) Thou shalt not use Response.Write. This includes the shorthand <&#37;= somestuff %>.
    Also debated & explained above. One should never, ever use Response.Write() in the code behind/code beside parts of a page (that is the back-end code) as it does horrid things to the .NET page lifecycle model. If one must emit text to the output stream, send things to the HtmlTextWriter that stores the response instead.

    Inline the debate is a bit thicker. I, myself, use databinding (<%# somestuff %> to page-level variables rather than including calls to Response.Write (which can be shorthanded as <%= somestuff %>).

    Hope this helps.

    Last edited by Jelena; Apr 3, 2007 at 05:12.

  14. #39
    SitePoint Addict Sojan80's Avatar
    Join Date
    May 2002
    Location
    Central WI, US
    Posts
    262
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99
    Bottom line is to only use them where having an in-memory representation of the database makes sense.
    So only use them if you have to do something sort of like paging a recordset? Say you have a catalogue of the 300 DVD's in your collection which you want to display to the user 50 at a time?

  15. #40
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Not quite, as that is a rather simple database hit. Much more useful in situations like benjymouse explained where one needs repeated, random access to the data.

    Furthermore, DataSets really start to creak when they get large.

  16. #41
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99
    Furthermore, DataSets really start to creak when they get large.
    Not to mention that the buggers reorganizes themselves internally when you do SELECTs on them, which means that references can be screwed up in a concurrency situation.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  17. #42
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by M. Johansson
    Not to mention that the buggers reorganizes themselves internally when you do SELECTs on them, which means that references can be screwed up in a concurrency situation.
    Could you explain that? Do you mean to say that if I'm holding a reference to a DataRow it might me invalidated by a select?

    As I have understood it, a DataView (or perhaps a Select) may trigger an index generation to speed up things. I've never heard that the public interface objects (like DataTables, DataViews, DataRows, DataColumns, ...) were subject to nondeterministic changes..?
    /mouse

  18. #43
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Benjymouse
    Could you explain that? Do you mean to say that if I'm holding a reference to a DataRow it might me invalidated by a select?
    Well, kind of. It's actually very wierd, and because of the extreme randomness that occurs in concurency situations, I have not been able to fully replicate it, but I can say with 100% certainty that you will have severe concurrecy problems if you don't make sure that only one thread Selects from the dataset at once.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com

  19. #44
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On

    29) Thou shalt not use Response.Write. This includes the shorthand <%= somestuff %>.

    Response.Write is bad when used in a page. And it's always bad in a page. I've searched my mind for just one good exception. But there aren't any. If you do custom controls you would use a HtmlWriter. If you want to output binary content you would be better off using a handler (Generic Handler).

    But I have come to realize that the shorthand <%= somestuff %> is not half bad. For one, it has well-defined semantics, i.e. it is evaluated during the rendering phase. And used correctly it will actually promote the "passive" model-view-controller pattern. Instead of the codebehind "setting" the values of the controls, they can fetch the values from the model.

    So I would suggest

    29) Thou shalt not use Response.Write. Not in pages nor in usercontrols. Not in markup nor in codebehind. (You *may* consider it when writing custom handlers, in which there's no page lifecycle to disturb).
    /mouse

  20. #45
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Time to bring this puppy back to life.

    35. Thou shalt use parameterized sql. Thou shalt never use string concatenation to create sql statements.

    [DISCLAIMER: this should not sink into the dynamic sql vs. stored procs debate going on for the 57th time in the blogoshpere at the moment. It can be said that both sides do agree that you should be using parameters, whatever sort of statement you are feeding the server]

    There are a number of reasons for this. First is secuity--parameterized sql should be correctly declared with the proper sql datatype. And the database server will properly escape the values contained within the queries.

    The second reason is speed. Sql server especially, but most database engines in general, are very good at caching execution plans for queries if they fed to them properly. In Sql's case, the "proper" format is parameterized.

    Finally, it is much, much cleaner to bind to parameters rather than manually crafting SQL. Especially when one starts to do things like build data access into a generic layer. So, do it for yourself and the guy who has to maintain this app behind you.

    36. Thou Shalt Not use sp_exec in your database. If you must use dynamic sql within database calls, use sp_executesql instead.

    I was reviewing an application today where the devs decided that they were going to use reasonably good practices in the .NET end of things. Typed Data Sets, parameterized Sql, etc. Then I got into the sql and it got real ugly real fast as they built the command strings in sql and then used the sp_exec to run them.

    This is bad because there is no caching of execution plans. Nevermind the ease of creating errors as Sql string formatting/clensing is limited at best.

    There are some situations where one must get a bit dynamic with the Sql. But you should use sp_executesql rather than sp_exec. The former procedure is much better as the sql it executes is a "first class citizen" so to speak and can take parameters as well as have its execution plan cached.

    PS: 95% of the places one sees bad dynamic sql is where someone wants to do something like "SELECT * FROM foo WHERE id in List (@List)"--which does not work in T-SQL. And there are all kinds of ugly hacks and workarounds to get around this. In any case, a SQL MVP named Erland Sommarskog posted a really awesome guide to how one should do this properly.

    PPS: Also see his article on the Curses and blessings of dynamic sql.
    Last edited by wwb_99; May 27, 2006 at 08:22.

  21. #46
    SitePoint Enthusiast navtej's Avatar
    Join Date
    May 2006
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99
    Great idea!



    4. Thou shalt not use DataSets in web applications.

    Thats all for now, stay tuned for more.
    Hi why not data sets

  22. #47
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    ^^^^Read page 2.

    Basically because in many places they are highly inefficent and encourage a 2.5 tier design.

  23. #48
    ALT.NET - because we need it silver trophybronze trophy dhtmlgod's Avatar
    Join Date
    Jul 2001
    Location
    Scotland
    Posts
    4,836
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's an article I like to keep handy for that very question: http://aspnet.4guysfromrolla.com/articles/050405-1.aspx


  24. #49
    SitePoint Enthusiast navtej's Avatar
    Join Date
    May 2006
    Posts
    74
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dhtmlgod
    Here's an article I like to keep handy for that very question: http://aspnet.4guysfromrolla.com/articles/050405-1.aspx

    Thanks for enlightning

  25. #50
    Wanna-be Apple nut silver trophy M. Johansson's Avatar
    Join Date
    Sep 2000
    Location
    Halmstad, Sweden
    Posts
    7,400
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    As a person who has an entire eCommerce site built on datasets, I can safely say that thea are tehpenis.
    Mattias Johansson
    Short, Swedish, Web Developer

    Buttons and Dog Tags with your custom design:
    FatStatement.com


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •