Well, I'm just learning ASP.Net, and after reading some books I found that there are this things called Modules which tweak a Request and Handlers that (I think) tweak a response. The problem is that I can't understand how they really work, so I prefer just skip this part and come back to them when I get a bit more comfortable with the ASP.Net framework.
My question is, are they a big part of this framework? Am I going to use them a lot?
ASP.NET modules and handlers are definitely important, but typically they are secondary to pages and services: so it is reasonable to focus on pages and/or services first.
As your understanding grows, modules and handlers will probably start to make more sense when you revisit them.
Having said this, a related SO question explains ASP.NET modules & handlers about as simply as one could hope for.
Related
Disclaimer:
This is the first time I am asking a question that might be classified as subjective. As English is not my first language, it is hard to phrase this right. So please feel free to edit the question in order to make it clearer, or to point me at other ways for asking this.
Intro:
David Ebbo (architect on the ASP.NET team) just posted on Register your HTTP modules at runtime without config using the seemingly undocumented PreApplicationStartMethod assembly level attribute
I have mixed feelings about it.
On the one hand it is good to be able to do things as early in the application startup phase as possible.
On the other hand: Does it suffice? Do we need a PrePreApplicationStartMethod allowing to fiddle with the PreApplicationStartMethod behaviour? What about expansion to non-assembly use (for instance, NuGet already works around the single-use-per-assembly restriction of PreApplicationStartMethod)?
Question: Besides using it for config-less startup, what do you think of the PreApplicationStartMethod attribute?
I think one of the good usages for this is that it allows someone who is writing a 3rd party assembly, or a team that is working on an assembly that will be used in many projects, to be able to use this attribute to initialize stuff w/o requiring the end user/developer to create anything in the global.asax in the application startup events.
There are lots of app specific stuff that people like to/need to configure in global.asax, but if you are creating a DLL, you no longer have to make the user configure your classes in the global.asax, you can just put all your logic in your own init/bootstrap function and rely on asp.net to call your init logic when the app starts.
For our company I'm creating a big Extranet website which will feature a set of sub-applications. I'm a bit puzzled by what should be the right setup of the solution and projects.
I have one web application that we call the Portal. It contains the authentication/authorization classes, masterpages, navigation/url routing classes and theme definitions. It will also contain some basic overviews for our customers to get a quick idea of their project status.
In the coming year we are going to develop and integrate more applications with the portal. Think of it as detailed overviews and tools called Feature A, B and C. Over the years we will improve these applications and release new versions. These web applications should fit into the navigation of the Portal seamlessly. I'd like them to reuse the masterpages and themes.
What is the proper way to setup this solution?
How can I tie the applications together, re-use the master pages and keep it maintainable?
How can I share certain webcontrols (ASCX) in a proper way?
We are using TFS, perhaps any branching/merging ideas?
Edit:
I'd like to create it in ASP.Net WebForms, we have the most experience in that area. But basically we can use anything, we've got the webserver under our own control (as long as it is Microsoft oriented, not switching to php or something like that :))
What is the proper way to setup this solution?
The proper way... There are so many. I have seen a lot of applications, and a lot of different setups (a lot of which that I would deem "proper"). What you're really asking is for the best way for your situation.
Because you're building a portal, you'll have the luxury of feature separation which will help you as you develop additional features for your application.
I would setup a single website with a separate folder for each feature. Making it a single website will allow all features to share the same masterpages, usercontrols, and configuration file - without having to do anything special. (On that note, I would put all your master pages in a folder by themselves, and create another folder for your usercontrols).
How can I tie the applications together, re-use the master pages and keep it maintainable?
Again... folders are the best option here. Folders will help separate each feature, making the application easy to manage.
How can I share certain webcontrols (ASCX) in a proper way?
First of all, ascx files are not webcontrols. They are usercontrols. WebControl is a class for creating server controls that reside in a separate assembly. Regarding usercontrols, as I said above, if you put them in a separate folder, they're always in one place and available throughout the application.
We are using TFS, perhaps any branching/merging ideas?
There really isn't anything special you need to do here. There are a lot of different paths you can take regarding branching:
One is to create a branch for every release.
Another is to create a branch for every new feature you add (in your case, this is pretty much the same as the first option).
Yet another is to create a branch for each developer.
When I decide how I am going to branch my code, I think about what will protect me the most. In your case, you need to plan for bug fixes in between feature releases so maybe one branch after each release makes the most sense (call it your dev branch). Given the separation of features, though, one feature may not effect the rest of the application. You may not need this kind of branching to be safe.
As Brian says when making an API public you should commit to it as much as possible, which means it should change as little as possible after the initial release. However to make something that stable requires lots of effort up front so if you aren't ready to commit to the API you should instead internalize it as much as possible and for that reason you might want to combine things more than separating them.
However, I'm not going to suggest an architecture that fits your application based on a 5 paragraph description. What you need to do is to weight pros and cons of having a few big projects vs. having a bunch of loosely coupled small projects. I mean, the more planning you do up front, the easier you will have it down the line, provided you stick with the plan.
So contrary to Brians answer, I wouldn't recommend you make your entire system "as loosly coupled as possible", only that you make it as loosly coupled as it needs to be. ;) Loosely coupled code can cause as much trouble as tightly coupled code, if you are abusing it.
See:
1. What is better, many small assemblies, or one big assembly?
2. Specific down-sides to many-‘small’-assemblies?
In the end, only you know how much you want to focus on each of the "...bilities", maintainability, extensibility, reliability etc. So get your priorities and goals straight and plan accordingly.
Regarding branching strategies you could read the TFS Branching Guideline 2.0 which have a good introduction to various branching strategies ranging from basic to advanced. Even if you don't use TFS this is a good guide to read (I use SVN at the moment). Since I currently work in small teams with 1-4 devs, I tend to use a strategy that is between basic and standard. Not that I'm recommending this for you, but that whats works best for our team.
As for sharing code between projects. In SVN we can use "externals" which means that the shared file will appear in several folders so when you change one copy and commit the change to svn, all the other copies will be updated on the next svn update. However, I can't remember if TFS have something similar.
Note: Beware of externals in SVN... they can cause... problems. ;)
My advice is to try to avoid sharing aspx, ascx and master pages as much as possible. It usually hurts a lot more than it helps. Instead try to use inheritance or other alternatives to achieve your goal.
ASP.NET MVC 2.0 has a concept called "Areas" where you build subsections of an application in isolation from the rest. As far as I know these areas can be maintained in separate projects from the "main" application. It sounds a lot like what you are requesting so maybe you should look into that.
Hope it makes sense. ;)
I would look at making your system as loosely coupled as possible. As/when you add more applications, your website will become less and less reliable (since no component will be up 100% of the time, combining these will reduce your overall reliability). So you should build your system to cater for the non-major services being down (I believe the Amazon homepage, for example, has 100-ish services contributing to it, and as such it's built to be fault-tolerant)
Your APIs between services should remain as stable as possible, such that the implementations can change without breaking the coupling. You should also investigate automated testing of this at the web level (perhaps Selenium or similar?) since testing the individual services will give you little coverage re the overall behaviour.
You might find it useful to look at implementing a custom VirtualPathProvider. On my last project we had multiple ASP.NET sites which needed to share theme files (master pages, user controls, images, style sheets) so I created a VirtualPathProvider which allowed us to map a virtual folder (e.g. /Themes) to any physical folder on the hard drive (e.g. C:\Shared\SiteThemes).
It's not trivial but didn't take too long and hasn't caused any problems. Incidentally it turned out to be a great way to overcome the maximum component limit in WiX... Note that you can't precompile sites that use a VirtualPathProvider.
Use MVC Concepts from now. they give more extendability and flexibility for a robust applications.
You might look at using SharePoint. It's a pretty decent platform for ASP.NET application delivery, particularly if they coexist in an intranet environment; it gives you a lot of stuff for free.
Of course, it has very rough elbows, so to speak, so proceed with caution.
I wouldn't think of the applications as seperate but as modules of the overall portal.
I would recommend you look into MEF as this would seem to be a perfect fit.
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx
What's the best way to log in ASP.net MVC? I mean any event, I'm currently using NLog but I know there are a lot of possible ways to do it.
I use log4net, its quite good. There are some issues to be aware of, you can learn more about them here. I also recommend Elmah, for me I use it on every project I do, its a prerequisite.
I don't think there is a best framework/tool or standard way in ASP.net MVC. Just do it the way you would in any other framework. When I set up logging, I usually think of it as a resource available to the rest of the application, rather than being tied to a particular tier. This is common, and in fact logging is the standard example given when introducing Aspect Oriented Programming. See:
Logging mentioned in the wikipedia entry on AOP
Another AOP into that uses logging as the example
Depending on what exactly you're trying to log, consider using action filters; a great way to log what page requests are made and for error handling coverage. Non-MVC asp.net apps usually do something in the global.asax, as mentioned here. In fact, even if you use the action filters, which I would suggest, also include some basic error handling in the global.asax 's application_error event; it will fire a little more dependably than the action filters if something really crazy happens.
Other than that, call your logging resource at the point where the stuff happens that's interesting to you. DB or File? Either works, and as long as it's encapsulated in a good method or two, you can always switch that later.
I have a portfolio made in C#/ASP.NET which started off small but, as it is selling myself, it has grown in size very quickly.
I started off with using ASP.NET webforms model but this has meant that some of my code is in class libraries (.dlls) and some in page codebehind.
I want to fix this (no defined stucture), but without the overhead of migrating to ASP.NET MVC or WCSF.
How could I address these problems? I am thinking of moving all logic to WCF services and calling them from page codebehind. Is there a better way?
EDIT: The current problem is codebehind (used only as the site was small at the start but now it gets a lot of attention from me with updates). I want to seperate this all out so it's easy to test (what MVC addresses), and the coupling is generally low. Is it enough to use WCF to achieve this? What other techniques could I employ? Maintainability is another concern because maintaining a codebase split between .dlls is awkward (when debugging, as I noticed and mentioned in some previous threads).
Thanks
Unfortunately, traditional web forms applications are damn near impossible to test. WCF won't be of much help because it's a communications technology that will help you to get the data to codebehind classes but won't help you to render or test pages.
Due to this complexity, there are very few test automation tools, and the few there are are commercial paid-for products. One such tool I have heard of, but have not used personally, is Ivonna. You can also test using browser automation. Two great tools to help with this purpose are watin and WebAii.
This is, of course, dependent on whether you still want to keep the original code lying around. What I take in when I read your post is that you want all of the benefits of MVC. Unfortunately, it may be best to take the plunge and rewrite the application. It's painful, I know, but the sheer amount of hackery to make WebForms ape MVC concepts is overwhelming, to say the least.
I cant fully imagine what you need, but consider URL redirection / slug
I realize that ASP.NET MVC has all the hype. I have my doubts that I need it, but wanted to explain my potential project:
This is an internal LAN application. It is doing CRUD operations and a little reporting.
The user base is small (< 12 people) and there is not tons of data
There is not a huge number of screens (Maybe 20)
I don't care about URL rewriting
My view state is typically small (like a DealID or ClientID)
Even though I don't have a full mastering of Page Lifecycle, I do understand Postbacks and don't have a problem coding for it.
I believe in Layering and am familiar with the M-V-P pattern and other patterns.
I want to do some Unit testing, but heck 25-50% coverage is better then what most apps.
The app will have a little AJAX for search screens, but don't see it being overkill.
So what do you think? While using the "sexy" technology is cool, is it necessary?
No, it's not necessary. It sounds like you've already made up your mind. If the application isn't all that critical and you're more familiar with web forms, just do it the way you know how to. I think ASP.NET MVC is worth learning, but it isn't the right solution for every project. Go and try it out in your free time so that when this situation comes up again, you'll have more options available to you.
No you don't strictly need MVC but are you asking whether you should learn something new or use what you already know for an internal project? An internal project might be the perfect place to try out something new.
As was said, it's not necessary. However, if you're doing a basic CRUD application (and it sounds like you are), MVC would make that nice and easy.
You mention you're moving to project management. Do you think any of the projects or products you look into will be using MVC? If so then at least you'll have some familiarity by learning it with this small application. This means it is necessary, if you need it as a PM, but you do not require it just to build the app. It could run with anything you choose.
Incidentally, ASP.NET MVC is new, not MVC, not by any stretch of the imagination. I know you did not say it was, but you mention hype. I cannot help but think Java and other folks are saying, "We've been doing this for years and years."
You can use both.
Create a Visual Studio Web Application (not a website), and you'll be able to use both if needed.
You'll just need to add a reference to MVC and setup the routing.
Webforms and MVC
It's not necessary, no, but there's no reason why you can't use webforms or MVC.
If you feel comfortable working with webforms, then go down the webforms approach. If, however, you feel the need to broaden your knowledge of architectural patterns, then ASP.NET MVC is a pretty nice thing to use.
If unit testing is important to you, go with MVC. Everything else you mentioned, though, points to WebForms.