Boosting Your .NET Application Performance - Security
(Page 4 of 7 )
In ASP.NET there are 4 security models that you can use in your web applications.
1. Form security This is probably the most commonly used security model in ASP.NET web sites. It's very convenient to use and is perfect for most applications. If you need role based security then typically this is the way to go.
2. Passport If you want your visitors to be able to use their passport account at your site, you can implement the passport security model. To use this security model you need to be able to access the Internet, so it's not really suitable for intranet applications. It's quiet flexible and quite effective, however. As a passport user myself, its very convenient not to login to each and every site I visit. But all of this come at an expensive dollar price!
3. Custom Security If you need a more complex security system, then you will need to implement your own security system. This is typically done by building your own principal and identity classes (implementing the IPrincipal an Iidentity interfaces). I've implemented permission-based security using this method and it was very successful.
4. Windows Security This is perfect for intranet sites. It communicates to an Active Directory for user authentication information where all of the groups, permissions and users are managed.
Business Tier Issues Building an efficient and elegant Business Tier is very important. If your business tier code is slow and hard to understand, then there is no hope of making an application fast or extendable in the future. It doesn't matter how efficient your presentation code is (by calling on the business tier less often) -- if your business tier is making unnecessary round trips to the database, then your application as a whole will be slow.
This is a little different from what I've said about the presentation tier. If the presentation tier is slow, then that part of the application might be slow, but if its the business tier that's slow, then it will affect all applications that use the business tier, which can be ASPX pages as well as web services you provide to other businesses.
DataSet VS DataReader The issue of the DataSet versus the DataReader for some reason always seem to put people in doubt. I've come across a lot of people who weren’t sure which one to use. Let's clarify their uses now.
In ASP.NET, always use a DataReader unless you need to serialize it or pass it to the next tier. There are some books and articles that tell you to use a DataSet over a DataReader every time. In my opinion that's not good practice because a DataSet eats up your resources very, very quickly (a DataSet actually is filled using a DataReader).
I rarely use a DataSet in my web applications. I always use a DataReader, and if I need to pass it to the next tier I make my own custom collection class and pass that object between tiers. I just find a DataSet too heavy for web applications, though for a web service it's better to use a DataSet than a custom collection.
Note: I'm talking about just the web application. This becomes a different story if you're designing BLL for both Web AND Win forms
Some people might have heard of typed DataSets, which are classes that inherit from the DataSet. It is used in Duwamish7 and is quite popular in the .NET community. It has a very elegant design, but compromises your application’s performance. If elegance is more important (for future upgrades), then a typed dataset is a great alternative to your own custom collection. VS.NET has great support for them too!
Next: Class Design >>
More ASP.NET Articles
More By James Yang
