I am new to .NET and ideally want to make several layers of abstraction for making a fairly complex website. Being the first layer handling login, authentication, etc, with another layer handling the built in apps (how they look, predefined functions, database connections), and the lower level will be specific app implementation details.
This favors uniformity as all apps will inherit from one place allowing for easier maintenance and rapid development of all the smaller apps once the overhead abstraction layers handle their responsibilities.
The only problem is I am not 100% sure where to start with .NET ASP webpage inheritance. I tried Google and searching but I may not be looking for the right thing. I am hoping with someone with experience on the matter may direct me towards resources to make this kind of webpage inheritance/abstraction easier!
I am using Visual Studio 2010.
Edit:
I also want to add the purpose to my question: Another individual is creating the base of the website which will handle authentication, portal, UI look, etc
I want to make an app base that uses their website framework and adds onto it standards that every app must meet, function library, any addition UI overrides not applicable from portal, etc.
From there a third layer that will directly inherit from the above app base framework (abstraction) and further specify based on the guide lines made.
I appreciate the feedback so far!
In ASP.NET you have 4 common ways to reuse code/abstractions to serve you application-wide
The first way is just using a base page, which will inherit the standard asp.net Page and share the common logic for all of your pages, as explained here
The second way is using a master page: a master page defines a common design (html / css - wise) for all the pages that use it throughout the application. It can also be accessed programmatically by pages that use it, and therefore share a common logic
The third way is using an http module: An http module is basically a class, which is responsible for handling an HTTP request before its handled by the expected pages code on the server, and it allows you to add any common logic you want your application to use (such as authentication / authorization handling, getting relevant user information from the DB, etc)
Global.asax: contains application/session wide event handlers, which allow you to handle those events in once place (everything from application starting to a user session ending)
Using modules and base page is the preferred way, if you want to build few applications, sharing common behaviour. A master page can be used as well, of course, if you want them to share the same design as well.
That's quite a broad question. Welcome to ASP.NET!
I would suggest researching these topics:
Web page inheritance -> Master Pages,
Skinning -> App_Themes,
separation of responsibilities -> MVP design
pattern for the Web Forms platform, or MVC if you have a choice.
Login, roles -> Membership
Related
Learning new things needs an investment of time, space and energy. I am currently learning Asp.Net Core MVC 2.0. This ASP.NET Core tutorials overview states:
Razor Pages is the recommended approach to create a Web UI with ASP.NET Core
This information confused me in deciding whether I have to stop learning Asp.net Core MVC and start learning Asp.net Core Razor Pages.
Why is Razor Pages the recommended approach to create a Web UI in Asp.net Core?
Any directions are welcome.
From this article in Microsoft docs:
MVC: Using controllers and views, it was common for applications to have very
large controllers that worked with many different dependencies and view models and returned many
different views. This resulted in a lot of complexity and often resulted in controllers that didn’t follow
the Single Responsibility Principle or Open/Closed Principles effectively.
Razor Pages addresses this
issue by encapsulating the server-side logic for a given logical “page” in a web application. A Razor Page that has no server-side logic can simply consist of a Razor file (eg. “Index.cshtml”). However, most non-trivial Razor Pages will have an associated page model
class, which by convention is named the same as the Razor file with a “.cs” extension (for example, “Index.cshtml.cs”). This page model class combines the responsibilities of a Controller and a ViewModel. Instead of handling requests with controller action methods, page model handlers like “OnGet()” are
executed, rendering their associated page by default.
Razor pages simplify the process of building
individual pages in an ASP.NET Core app, while still providing all the architectural features of ASP.NET Core MVC. They are a good default choice for new page-based functionality.
When to use MVC:
If you’re building web APIs, the MVC pattern makes more sense than trying to use Razor Pages.
If your project will only expose web API endpoints, you should ideally start from the Web API project
template, but otherwise it’s easy to add controllers and associated API endpoints to any ASP.NET Core
app. You should also use the view-based MVC approach if you’re migrating an existing application
from ASP.NET MVC 5 or earlier to ASP.NET Core MVC and you want to do so with the least amount of
effort. Once you’ve made the initial migration, you can evaluate whether it makes sense to adopt
Razor Pages for new features or even as a wholesale migration.
Note:
Whether you choose to build your web app using Razor Pages or MVC views, your app will have
similar performance and will include support for dependency injection, filters, model binding, validation, etc.
Update: Some more reasons i read on this github issue commented by scott sauber:
We're using Razor Pages for a [complex] Health Insurance portal... We have 60+ pages and I can say that for Server-rendered HTML, I will never go back to MVC. It's also not just for simple things. The Health Insurance domain is inherently complex and combine this with the fact that it's a multi-tenant app (we sell the product to other insurance companies), which adds more complexity as the app is highly configurable as different insurance companies do things a bit differently.
Why use it?
Razor Pages is more secure by default. Razor Pages gives you AntiForgeryToken validation by default. Plus you opt-in to what properties you want to be model bound via [BindProperty] which limits your exposure to over-posting attacks.
Razor Pages has a better folder structure by default that scales better. In MVC, the default folder structure simply does not scale. Having separate folders for Views, Controllers, and often ViewModels when all three are ultimately tightly coupled to one another is a huge PITA to work with. You end up bouncing to all 3 folders and navigating a bunch anytime you need to add or change a feature. It's horrible. This is why I advocated for Feature Folders. With Razor Pages, your PageModel (Controller + ViewModel) are in the same folder as your View. You can just hit F7 to toggle between them which is also super convenient.
Leads to more maintainable code that scales better. With MVC it was super easy to bloat a Controller with 10+ Actions. Often, these Actions weren't even related to one another in any way (except maybe a Redirect between the two). This made navigating the Controller to find code very difficult. It got worse if there were private methods in the Controller too, further adding to the method bloat. With Razor Pages, it's nearly impossible to bloat up your Page Model with unrelated methods to your page. Everything you put in your PageModel is related to your Page.
Unit Testing is easier. With a Controller, you might have 8 Actions and some of your dependencies you inject in were only related to one or two Actions. So when unit testing a single Action either you need to mock those out unnecessarily or pass a null, both of which feels gross (this can be solved a bit with the Builder pattern). With Razor Pages, the dependencies you inject in are 100% related to GET and POST actions you're working with. It just feels natural.
Routing is easier. By default in Razor Pages, routing just matches your folder structure. This makes nesting folders way easier to accomplish. For instance, all of our HR Admin pages are under the /Administrator folder and all the Employee pages are under the /Employee folder. We can authorize an entire folder and say the person must be an Administrator to get to any subfolder of /Administrator, which was way easier to do that than with multiple Controllers that make up the Administrator features.
I think that's the big stuff.
Update 2:
This is about some complexity of MVC pattern, does not directly answer the question but can be useful: An Engineering Manager at Facebook, said (here) for their “sufficiently” large codebase and large organization, “MVC got really complicated really quickly,” concluding that MVC does not scale. The complexity of the system went exponential every time they attempted to add a new feature making the code “fragile and unpredictable.” This was becoming a serious problem for developers new to a certain codebase because they were afraid to touch the code lest they might break something. The result was MVC was falling apart for Facebook.
Razor Pages are optimized for page-based workflows and can be used in these scenarios with fewer moving parts than traditional MVC models. This is because you don't need to deal with Controllers, Actions, Routes, ViewModels, and Views (as you typically would). Instead your route is convention-based, and your PageModel serves as your Controller, Action(s), and ViewModel all in one. The page, of course, replaces the View. You also don't have to have as many folders as you would in MVC, further simplifying your project.
From ASP.NET Core - Simpler ASP.NET MVC Apps with Razor Pages, a Sept. 2017 MSDN article by Steve Smith:
[Razor Pages] provide
a simpler way to organize code within ASP.NET Core applications, keeping implementation logic and view models closer to the view implementation code.
They also offer a simpler way to get started developing ASP.NET Core apps,
That article has more information on why to use Razor Pages over MVC for page-based workflows. Obviously, for APIs, you will still want to use Controllers.
3rd party edit - disadvantages of classical MVC folder organization
ASP.NET Core - Feature Slices for ASP.NET Core MVC, an older MSDN article from Sept. 2016, describes why the classical MVC convention to organize views and controller might have disadvantages for larger projects. The article gives an example of four loosely related application concepts: Ninjas, Plants, Pirates and Zombies. The article outlines a way to structure them outside of the default folder convention by organizing files into folders by feature or area of responsibility.
Microsoft is coming back to the WebForms approach to simplify the project structure trusting in the "Convention over configuration" mantra, while hiding the configuration from developer to make things faster. But it has the disavantage that everything will be mixed again. It doesn't look like a smart move for organizing. But... Hey! Something new must catch the attention of the dev towards Microsoft.
If your page uses an MVC Web API for the REStful, it's really more easy to just use Razor pages. If not, I would recommend you to use Core MVC.
In huge projects, where the model and controller are together in the same file, maintenance will be a nightmare. It works well for clases that are just 2 properties long, but it violates the Open Close Principle of OOP. You should design and use an architecture that can grow with time (Extensible) and still be stable and logic(No reestructuring the project), just extend it using the same pattern.
As a Software Architect I use design patterns automatically. What I like a lot is the Facade design pattern. You hide everything related to Home behind a HomeController and you can do the same with Repositories.
Want to know a funny thing? A tour guide explained where the name
Facade comes from. In Amsterdam you have big houses across the waters.
From the outside they look luxureous. But from the behind they can be
messy. The facade of the house hides whats behind it. Design patterns
comes from the building world. Well whats behind in my applications
also looks good but it was nice to know from the tour guide about the
explanation.
What about support for Sharing and Grouping actions in Razor pages. If you look at MVC Controllers you can see that you can Group controller actions based on functionality. You could say the Home page is such a functionality. Then you have a HomeController with About() and Contact() in it, but with Razor Pages this would be different pages. May be you have a big HomeController with lets say 5 other Views in it. They can all be grouped in the same HomeController.
A Controller has two things a Razor Pages does not have:
Sharing: You can share Controller actions between different pages, sometimes controller actions are not bound only to one page but can be shared between several pages. Remember Controller actions can also only return Data (JSON/XML/etc). Sometimes what they return can be used by different pages too.
Grouping: You can group related Controller actions together in one Controller. Ok if you are a fan of small Controller files you won't do this. I do. I group my Controllers based on functionality. That makes navigation much easier.
What is the Razor pages way of handling this: Use of directories I think:
Grouping: If we have the HomeController, then we could make a subdirectory Home with all the Home pages in it.
Question: For a simple Home that would be enough. But lets say we have an XController that uses for all actions the same Repository. You could initialize that Repository in the Initializer function of the XController. But for pages in the X subdirectory you would have to do that for all X actions again. Is that DRY?
Sharing: You could make a "Share" subdirectory and under that, directories with functionality that should be shared between pages.
Question: If you look at my fix you can see I use directories to solve the Share and Grouping problem of Razor pages.
How would you do this?
or...are Razor pages just meant to be for simple websites, could this be the conclusion for this version of Razor pages.
Blazor server has a strange architecture. It looks like a chat application by use of SignalR. My experience with applications like that is that events can get lost. I don't want to lose events, better is they are stacked and guaranteed to be processed like mail.
Developers were on forums in 2013 asking "What does Microsoft mean, Silverlight is not the recommended ...???"
Only this time, it is that MVC is going to be pronounced dead and long live MVVM.
And you can likely expect MVC to be thrown to the scrap heap, slowly, but sped up in about 18 months from now, and any and all time you spent learning MVC will go to that same scrap heap.
Also, MVVM looks easy but it takes a year to get the hang of it and really do it right.
Im very new to programming and I'm wondering if someone can point me in the direction of how to make a website show 3 images that represent products and instead of redirecting me to another page but instead stay on the current page and show information about that product which can lead to a purchase.
I'd like to be able to build a SPA, but I'm in the early stages of learning HTML, Css and Javascript. What are the best framework to start using if i want to create a information website with just contact info, about me sections and so on.
The term what you are searching is Single-Page Applications (SPAs) which are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app.
To have smooth scroll and other animation effects, you need to write JavaScript that can run be executed in the client side. I strongly recommend you to use a framework which is specifically designed to develop client side web applications such as Angular, Jquery. There are lot of options and I can't just specify all of them nor recommend specific one without knowing your actual requirements.
Do a basic research on Single-Page Applications, client side web applications in Internet, you will find lot of frameworks and tutorials.
The simplest way to use single page application nowadays is using frameworks like bootstrap. You could use their ready functionalities.
I'm looking for best practices and good ideas rather than a proper solution.
scenario: I work in a web agency and thus we are plenty of websites from several customers. They're built upon a cms we made, so websites are quite identical for the 90% of code. However, remaining 10% struggles me and my team as it involves not only the presentation layer but behavioral logics too (ex: a website1 requires simply user/pass registration while website2 needs more data, facebook connector, etc. But this is a very easy example).
Making ad hoc development for our customers is becoming painful as keep each version aligned is getting really hard for us
What I really dream to have is an extendible website that works by itself, but in which I can override a part. This behavior should sound like "look for the specific part, if it doesn't exists get the base one". The parts could be a method, a class, a page, a control, a static file.
example:
Suppose I want website2 to have an own login component, let's so imagine that we have a situation like:
/website_base
|_ login.aspx
/website1
/website2
|_ login.aspx
So, if I ask for www.website1.com I'll get /website_base/login.aspx, but if I ask for www.website2.com I'll get /website2/login.aspx
Any idea?
Thanks
PS: we work with asp.net 3.5 framework.
There are couple of ways to achieve this.
Approach 1:
1. Split the common functionality in modules and create a pluggable structure. (like DotNetNuke) Obviously this will be more time consuming initially but over the period of time it can make itself like a product.
Approach 2:
Firstly - I would create separate solution for each client for better maintainability. This will save me a lot of hassle while maintaining the source control and when one client comes back with issues and we have multiple releases for a single client.
Secondly - From my core solution, I will identify most commonly used artifacts for each layers and move them to a core assembly.
a. For example – In UI you can use themes to give different looks for each client. Have a default master page which comes with the core site structure. All client specific details like Logo, name, contact details etc… can be configured using some DB fields.
b. In Business Layer and Data Access Layer – core functionalities like Membership, Logging, CMS related Entities etc I would have as a dll
i. I will derive my client specific logic from these core classes.
Last but not the least – how you deploy your code and how your IIS VD structure looks like… I believe it will be totally dependent on how the solution is packaged.. I would create a deployment package for each client which will give them the ability to deploy it to any server wherever they want until you have specific issues about proprietary software hosting.
Look into ASP.NET MVC. It is much more extensible than Web Forms, can be integrated into your existing Web Forms application, and it is very easy to build reusable custom components like what you are describing.
Otherwise, I would suggest looking into WebParts and developing reusable custom server controls for the components that you need. This way you can encapsulate the complex functionality within a single UI control without having to write repetitive code. WebParts are also compatible with Personalization, which you can leverage to manage the variance between which sites use which controls.
I definitely recommend MVC as the way to go for building extensible .NET web applications, but learning a new technology always incurs a cost in the time it takes to understand the new paradigm. I hope this helps you.
I found a smart solution here: http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx
Check it out
I think many of us used to face the same question: what's the best practice to port existing web forms App to MVC. The situation for me is that we'll support both web forms and MVC at the same time. It means, we create new features in MVC, while maintaining legacy pages in web forms, and they're all in a same project.
The point is: we want to keep the DRY (do not repeat yourself) principle and reduce duplicate code as much as possible. The ASPX page is not a problem as we only create new features in MVC, but there're still some shared components we want to re-use the both new / legacy pages:
Master page
UserControl
The question here is: Is that possible to create a common master page / usercontrol that could be used for both web forms and MVC? I know that ViewMasterPage inherits from MasterPage and ViewUserControl inherits from UserControl, so it's maybe OK to let both web forms and MVC ASPX page refer to the MVC version. I did some testing and found sometimes it generates errors during the rendering of usercontrols.
Any idea / experience you can share with me? Very appreciate to it.
Background:
This UI project has been created for years and there're 20+ people working on that. Before I start the common master page trial, there're about 50+ web forms pages and only one MVC page. We create new features on MVC, but the old pages keep remaining in web forms.
This situation will keep for a long time, probably because this's a business-driven company so new features are always in a higher priority. This means we need to support both at the same time.
There are several integration problems using ASP.NET MVC master page with web forms pages and user controls. Since the execution pipelines of the two frameworks are not exactly the same it is normal to have some problems.
One of the things I've faced is that web forms uses single interface pattern (it has one <form> tag with runat="server" on the page). In your master page or pages using it you'll have to create this tag yourself if you want to use server controls. Note that this will work for read-only controls. If you need post-back & event handling you'll probably face more problems with event handling and event validation.
Also one trick is to create html helpers that render existing controls to string. You can check this out for more info http://www.abadjimarinov.net/blog/2009/10/29/HowToRenderAspdotNETControlToString.xhtml This is also a partial solution as it will not work with most user controls.
It will be helpful to provide some code or error messages so I can give you more concrete answers. At this level I can only say that the two frameworks are compatible and you can integrate them but this will not be painless and will require some changes in the existing code.
Let me use an analogy
This will sound harsh but will make it easier for me to pass the idea across. Exaggeration helps sometimes because it emphasizes certain things that need to be understood.
Ok. We're using bicycles to get from A to B at the moment. We're considering buying a car but we want to make transition from one to the other as painful as possible. Consider the fact that we enhanced our bike so it uses custom pedals etc. Is it possible that we use these pedals and other enhancements with the new car we're considering?
Essentially it's possible. But without making a huge mess out of it it is definitely not advisable.
Suggested transition is to change pages one by one to use the new technology (new ones of course in the new technology) and not to introduce some MVC functionality to a webforms page. Either MVC or WebForms for a particular user process. Majority of non-UI code can be reused (business services, data access layer code, data/domain model when applicable). But if you're cramming all the code in your code-behinds... Well bad luck for you. If you haven't separated your code you will more or less be repeating code. Unfortunately that's not Asp.net MVC's fault. It's your bad design without SoC.
Don't combine/mix/blend two UI technologies if you're not suicidal. You can go from A->B using either bike or car, but not both at the same time. This means you can have WebForms part of your application and MVC part of it, but not likely on the same page. And this is only possible if you use Web applications not Web sites. Asp.net MVC can't work as a Web site (on demand partial per page compilation).
Re-usability related to my analogy
Bike and car are two UI technologies. What you do or the purpose of you taking the route from A->B is not important. That's business logic. If you're delivering newspapers that's not related to transport. So you can see that other layers can be reused.
Asp.net WebForms vs. MVC
Asp.net WebForms
Server-side controls (web/user) use the event pipeline execution model. Hence they (unless completely presentational nature) have server side events that some code subscribes to. Platform is completely state-full and everything executes in a manner that abstracts the HTTP completely away. Everything looks like you'd be running a desktop application.
Controls usually encapsulate presentation, code (as in server-side and client side script) and style (as in CSS). That's why it's a lot harder to have SoC using WebForms.
Asp.net MVC
This platforms is completely suited for the stateless nature of the HTTP protocol. Every request is completely stateless (unless you store some state data in persistent medium - Session, DB, etc.). There's nothing like an event model. It's basically just presentation of data/information that is able to transfer data to the server (either as GET, POST, DELETE, PUT...). Server side doesn't have any events. It's only able to read that data and act upon it. And return some result (HTML, Script, JSON, ...). No events. No state. No complex abstractions.
Asp.net MVC abstracts away some common scenarios that are related to data. Like automatic conversion to complex object instances and data validation. Everything else is gone.
Asp.net MVC using WebForms
In case you would like to use server-side controls in an MVC application you would be able to put them in your ASPX/ASCX, but they would only be used as pure presentation. You'd provide some data to render. And that's pretty much it. Postbacks wouldn't even work (unless you'd put a submit button on it), because there's no __doPostback client side functionality that would make a POST request to the server. So if there's any server side code that these controls have (even when they didn't initiate a postback) and are related to it's state-full lifetime after they've been loaded, you can say goodbye to them. More or less.
Other than that, you can read a lot about differences between Asp.net WebForms and Asp.net MVC on the internet.
Sharing MasterPages: see this thread.
User Controls:
This is one of the banes of my existence with MVC; in MVC2 and previous revs, there's no direct equivalent to webforms user controls. A sort-of workaround is creating HtmlHelpers - (effectively extension methods to the Html object available in views that return HTML), but that means you'll have to render your HTML in code. Teh suck.
With MVC3 and the Razor view engine, a new class of Html Helpers is available that provides most of the benefits of user controls, including the ability to place them in separate assemblies (and therefore can be used in multiple projects). I'll see if I can dig up an example link, but Scott Guthrie's blog had an example in one of his recent MVC3/Razor posts.
You can do a certain amount of integration between the 2, but you end up with something more complex & less satisfactory from either approach. A comprise in other words.
I've had this same problem in the past & server side includes worked for me. Old school I know & not something I'd generally recommend. But we don't work in an ideal world.
At the moment I am starting to learn Silverlight. I have expriences in ASP.NET and like the concepts of "Masterpages. Does Silverlight provides a similar concept ? I have read a little bit about the Silverlight Navigation Framework. Is this a good replacement for "Masterpages" ?
Makes it sense to combine ASP.NET and HTML (with Javascript) with Silverlight or is it more recommandable to design and write pure Silverlight applications ? Mybe in the ner future I will start to develop an intranet (business) application which will have many and complex user interaction (it should behave like a windows client applicion). I think Silverlight is the better choice than ASP.NET !? Makes it sense also to start to use/learn the WCF RIA Services immediatly ?
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ? Unfortunately I am missing "Starter kits" on http://www.silverlight.net like the starter kits on www.asp.net !
Thanks in advance for your hints.
Silverlight and ASP.Net are light years apart technology wise, Silverlight is closer to Winforms programming than it is to ASP.net, event though it can be hosted inside an ASP.Net page.
To achieve "masterpage" type functionality, you can have a base control or page that you can inherit everything else from. Or you can have a page which acts as a shell and you can swap views in and out depending on the user's actions.
If you are writing an app from scratch, you can do the whole thing in silverlight. You can navigate from one silverlight control (hosted in an aspx page) to another aspx page (with silverlight controls in it), but there is a performance overhead when transitioning between aspx pages (they are web pages and need to be served). You should look to eliminate separate aspx pages if possible, and create it as one big silverlight application - if your application's functionality is all rolled into one application (not spread amongst aspx pages) then you can make the most of Silverlight's Out Of Browser feature.
However you should only consider silverlight if you are build web apps or interactive/streaming stuff. If your pages are going to be largely static (i.e. presenting product catalogs, or a site where the user just drills through from one page to another) then using silverlight would be overkill, you would be better off sticking with ASP.Net or ASP.Net MVC.
Masterpages does Silverlight provide a similar concept ?
Not directly but it does provide a variety of ways to acheive the goals of Masterpages. The navigation framework is mostly the sort of thing you would need to achieve the typical reason to use Masterpages.
However its also possible to achieve "masterpage" functionality more generally by creating a UserControl that has ContentControl instances at points where in ASP.NET masterpages you would have used a asp:contentplaceholder. These content controls would be bound to custom properties added to the UserControl. This completed UserControl can then be used as the "LayoutRoot" of another UserControl or Page. Note this does not require inheritence from the "master".
Does a combined ASP.NET and Silverlight app make sense?
Well thats a tricky one the answer really is, "It depends". There are way to many factors to give this a true answer. Factors:-
Is this a public app or an internal app?
How important are including rich UI features?
First time Silverlight dev will cost you, is your project able to absorbe that?
What client platforms do you need to support?
How might ASP.NET-MVC + appropriate use of JQuery size up against your requirements?
Probably others I haven't thought of yet
Is Silverlight is the better choice than ASP.NET when there are many and complex user interactions?
The phrase "complex user interactions" could mean a couple of things? Do mean complex to deliver with HTML and Javascript but simple for the user? Or is this a sophisticated app aimed at an expert user?
In either case its likely that Silverlight will start to come into its own here.
Does make it sense also to start to use/learn the WCF RIA Services immediately?
Yet again the answer depends of the type of application you have in mind. If its line of business app where data is searched, edited and reported on then (assuming you have decided to develop in Silverlight at all) definitely you should be looking at WCF RIA Services as well as the parts of PRISM that think are appropriate.
Other types of apps may not benefit from WCF RIA Services.
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ?
There are no start kits at present. However I think you will find what you need amoung the various demos and tutorials on the silverlight learning site.
I've particular found the videos useful. If you decide to go Silverlight its well worth clearing a day or two to got through the relevent ones.
These are a lot of questions at once.
Yes, the Navigation Framework functionality is pretty much equivalent to the Master Pages concept. Even to the point that it is tracked in the URL when users navigate, so they can use the back and forward button of their browsers.
If you want to do a stand-alone Silverlight application or a hybrid pretty much depends on your requirements and on the type of application you want to develop. If it's a Line of Business application, you might be doing fine with Silverlight alone.
For a public, content/text-intensive website probably HTML with some silverlight gadgetry here and there might still be preferable.