Department of Economic Informatics and Cybernetics

Bucharest University of Economic Studies

Web and Cloud Security

ASP.NET MVC Core 2 – Part I

Liviu-Adrian Cotfas,
liviu.cotfas@ase.ro
PhD.
ASP.NET MVC Core, C# Language

C#
• url: https://docs.microsoft.com/en-us/aspnet/

2
About me

https://ro.linkedin.com/in/cotfasliviu

3
Administrative issues

Recommended Reading / Watching

 Pro ASP.NET Core MVC 2
 ADAM FREEMAN
 Now in its 7th edition, the best
selling book on MVC is now
updated for ASP.NET Core MVC.
 https://www.apress.com/gp/book/9
781484231494
 https://github.com/apress/pro-asp.
net-core-mvc-2

4
Administrative issues

Recommended Reading / Watching

 ASP.NET Core Succinctly (Free)
 Simone Chiaretta and Ugo Lattanzi
 In ASP.NET Core Succinctly,
seasoned authors Simone
Chiaretta and Ugo Lattanzi update
you on all the advances provided
by Microsoft’s landmark
framework.
 https://www.syncfusion.com/resour
ces/techportal/details/ebooks/ASP_
NET_Core_Succinctly

5
Administrative issues

Further Reading / Watching

Courses on Microsoft Learn -
https://docs.microsoft.com/en-us/learn/
 Free

 Courses on PluralSight - www.pluralsight.com

 Free trial (10 days)
 Free limited access through
https://azure.microsoft.com/en-us/free/students/

6
Administrative issues

API reference and Source code

 Documentation:
 https://docs.microsoft.com/en-us/aspnet/

 API reference:
 https://docs.microsoft.com/en-us/dotnet/api/?view=aspnetcore-2.
2

 Source code:
 https://github.com/aspnet/Home

 Various samples:
 https://code.msdn.microsoft.com/
7
Contents

8
Brief History of the Microsoft Web
Stack
Brief History of the Microsoft Web Stack

ASP.NET Web Forms

 Shortcomings ASP.NET Web Forms :
 View State weight: The actual mechanism for maintaining
state across requests (known as View State) resulted in large
blocks of data being transferred between the client and server.
This data could reach hundreds of kilobytes in even modest web
applications, and it went back and forth with every request,
leading to slower response times and increasing the bandwidth
demands of the server.
 Page life cycle: The mechanism for connecting client-side
events with server-side event handler code, part of the page life
cycle, could be complicated and delicate. Few developers had
success manipulating the control hierarchy at runtime without
creating View State errors or finding that some event handlers
mysteriously fail to execute. 10
Brief History of the Microsoft Web Stack

ASP.NET Web Forms

 Limited control over HTML: Server controls rendered
themselves as HTML, but not necessarily the HTML you wanted.
In early versions of ASP.NET, the HTML output failed to meet with
web standards or make good use of Cascading Style Sheets
(CSS), and server controls generated unpredictable and complex
ID attributes that are hard to access using JavaScript. These
problems have improved in recent Web Forms releases, but it
can still be tricky to get the HTML you expect.

 Low testability : The designers of Web Forms could not have

anticipated that automated testing would become an essential
component of software development. The tightly coupled
architecture they designed was unsuitable for unit testing.
Integration testing could be a challenge, too. 11
Brief History of the Microsoft Web Stack

ASP.NET MVC
 Launched in 2007 (CTP), 2009 (1.0);

 Based on the Model-View-Controller (MVC) pattern to keep a

clear separation between business logic and presentation logic,
allowing complete control over the HTML markup.

 Released as a separate library, one not included in the framework.

Thanks to this release model, and not relying 100% on the IDE for
the design of the UI, it was possible to easily update it, keeping it
more in line with the fast-paced world of web development.

12
Brief History of the Microsoft Web Stack

ASP.NET MVC
 Although solving the problem of the slow release cycle and
removing the HTML markup abstraction, ASP.NET MVC still suffered
from:
 One couldn't run .NET applications on a non-Windows system.

 The dependency on the full framework made the .NET apps less
suitable for high-density scenarios, like the cloud, where
hundreds of applications run on a single machine and must scale
up very fast.

 The complexity of the .NET project system prevented the

development of .NET apps outside of Visual Studio.

13
Brief History of the Microsoft Web Stack

ASP.NET Core
 built on .NET Core, which is a cross-platform version of the .NET
Framework without the Windows-specific application programming
interfaces (APIs).

 possible for developers to create ASP.NET Core web applications on

Linux and OS X/macOS.

 ASP.NET Core is a completely new framework. It is simpler, it is

easier to work with, and it is free of the legacy that comes from
Web Forms. And, since it is based on .NET Core, it supports the
development of web applications on a range of platforms and
containers.

14
Brief History of the Microsoft Web Stack

ASP.NET Core
 provides the functionality of the original ASP.NET MVC Framework
and includes the functionality that was previously provided by Web
API.

15
HelloWorld (ASP .NET Core 2)
First application

Installing Visual Studio 2017

 Visual Studio 2019 / 2017 are available in Community,
Professional and Enterprise editions.

 Community is available for free and has all of the features

required for day-to-day development. Download and run the
installer from www.visualstudio.com

 Professional is available through azure.microsoft.com/en

-us/free/students/

 During setup make sure that you select the .NET Core Cross-
Platform Development workload.
17
First application

Installing Visual Studio 2017

18
First application

New Project

19
First application

Selecting the project template

20
First application

Why use C#?

 C# (pronounced "C sharp") is a general-purpose, strongly typed,

type-safe language, object-oriented programming language,
designed for building a variety of applications

 Focused on developer productivity.

 C# syntax is based on the C & C++ syntax.

 Platform-neutral, but it was written to work well with the

Microsoft .NET Framework.

21
Model-View-Controller Pattern
MVC Pattern

 The Model-View-Controller Pattern separates an application into

three main components: the model, the view, and the controller.
The controller interacts with the model based on the requirements
of the request. It renders the appropriate view and supplies it with
the necessary data to display.

MVP MVC

 It’s a User Interface Pattern, therefore one of the many patterns

you will use in a complex project. 23
MVC Pattern - Components

 The model which contain or represent the data that users work
with.

 Views define how the application UI will be displayed.

 Controllers process incoming requests, perform operations on the

model and select views to render to the user.

24
MVC Pattern

 Each piece of the MVC architecture is well-defined and self-

contained, which is referred to as the separation of concerns .

 The logic that manipulates the data in the model is contained only
in the model;

 The logic that displays data is only in the view

 The code that handles user requests and input is contained only in
the controller.

 With a clear division between each of the pieces, your application

will be easier to maintain and extend over its lifetime, no matter 25
Models

 Models—the M in MVC - contain the data that users work with.

 There are two broad types of model:

 view models (presentation models) - represent just data
passed from the controller to the view,
 domain models - which contain the data in a business domain,
along with the operations, transformations, and rules for
creating, storing, and manipulating that data, collectively
referred to as the model logic .

Models are the definition of the universe your application works in.

26
Models

 In a banking application, for example, the model represents

everything in the bank that the application supports, such as
accounts, the general ledger, and credit limits for customers, as
well as the operations that can be used to manipulate the data in
the model, such as depositing funds and making withdrawals from
the accounts.

 The model is also responsible for preserving the overall state and
consistency of the data—for example, making sure that all
transactions are added to the ledger and that a client doesn’t
withdraw more money than he is entitled to or more money than
the bank has.

27
Models

The model in an application built using the MVC pattern should

 Contain the domain data
 Contain the logic for creating, managing, and modifying the
domain data
 Provide a clean API that exposes the model data and operations
on it

The model should not:

 Expose details of how the model data is obtained or managed (in
other words, details of the data storage mechanism should not
be exposed to controllers and views)
 Contain logic that transforms the model based on user
interaction (because that is the controller’s job) 28
Models

 The benefits of ensuring that the model is isolated from the

controller and views are that you can test your logic more easily
and that enhancing and maintaining the overall application is
simpler and easier.

 Tip Many developers new to the MVC pattern get confused with
the idea of including logic in the data model, believing that the
goal of the MVC pattern is to separate data from logic. This is a
misapprehension: the goal of the MVC pattern is to divide an
application into three functional areas, each of which may contain
both logic and data. The goal isn’t to eliminate logic from the
model. Rather, it is to ensure that the model only contains
logic for creating and managing the model data.
29
Controllers

 Controllers are the connective tissue in the MVC pattern, acting as

conduits between the data model and views. Controllers define
actions that provide the business logic that operates on the data
model and that provide the data that views display to the user.

 A controller built using the MVC pattern should

 Contain the actions required to update the model based on user
interaction

 The controller should not

 Contain logic that manages the appearance of data (that is the
job of the view)
 Contain logic that manages the persistence of data (that is the
30
Views

 Views contain the logic required to display data to the user or to

capture data from the user so that it can be processed by a
controller action.

 Views should:
 Contain the logic and markup required to present data to the
user

 Views should not

 Contain complex logic (this is better placed in a controller)
 Contain logic that creates, stores, or manipulates the domain
model
31
Views

 Views can contain logic, but it should be simple and used

sparingly. Putting anything but the simplest method calls or
expressions in a view makes the overall application harder to test
and maintain

32
ASP.NET Core MVC

 ASP.NET MVC is a framework for building web applications that

applies the general Model View Controller pattern to the ASP.NET
framework.

 In ASP.NET Core MVC, controllers are C# classes, usually derived

from the Microsoft.AspNetCore.Mvc.Controller class.

 Each public method in a class derived from Controller is an action

method, which is associated with a URL.

 When a request is sent to the URL associated with an action

method, the statements in that action method are executed in
order to perform some operation on the domain model and then to
33
select a view to display to the client.
ASP.NET Core MVC

34
ASP.NET Core MVC

 ASP.NET Core MVC uses a view engine , known as Razor, which is

the component responsible for processing a view in order to
generate a response for the browser. Razor views are HTML
templates that contain C# logic that is used to process model data
to generate dynamic content that responds to changes in the
model.

 ASP.NET Core MVC doesn’t apply any constraints on the

implementation of your domain model. You can create a model
using regular C# objects and implement persistence using any of
the databases, object relational mapping frameworks, or other
data tools supported by .NET.

35
Key Benefits of ASP.NET Core
Key Benefits of ASP.NET Core

MVC Architecture

 implements the MVC pattern and, in doing so, provides a greatly

improved separation of concerns when compared to Web Forms.

37
Key Benefits of ASP.NET Core

Extensibility
 ASP.NET Core is built as a series of independent components that
have well-defined characteristics, satisfy a .NET interface or that
are built on an abstract base class. Thus, it is possible to replace
key components with ones of your own implementation.

 In general, the ASP.NET Core MVC gives you these three options for
each component:
 Use the default implementation of the component as it stands
(which should be enough for most applications).
 Derive a subclass of the default implementation to tweak its
behavior.
 Replace the component entirely with a new implementation of
the interface or abstract base class.
38
Key Benefits of ASP.NET Core

Tight Control over HTML and HTTP

 ASP.NET Core MVC produces clean, standards-compliant markup.
Its built-in tag helpers produce standards-compliant output
 ASP.NET Core MVC encourages you to craft simple, elegant markup
styled with CSS.
 ASP.NET Core MVC makes it easy to use best-of-breed client-side
libraries such as jQuery, Angular, or the Bootstrap CSS library.
ASP.NET. Core MVC meshes so well with these libraries that
Microsoft includes support for them as built-in parts of the
standard Visual Studio project template for web applications.
 ASP.NET Core MVC works in tune with HTTP. You have control over
the requests passing between the browser and server, so you can
fine-tune your user experience as much as you like. Ajax is made
easy, and creating web services to receive browser HTTP requests
is a simple process. 39
Key Benefits of ASP.NET Core

Testability
 The ASP.NET Core MVC architecture gives you a great start in
making your application maintainable and testable because you
naturally separate different application concerns into independent
pieces. In addition, each piece of the ASP.NET Core platform and
the ASP.NET Core MVC framework can be isolated and replaced for
unit testing, which can be performed using any popular open
source testing framework, such as xUnit.

 ASP.NET Core MVC applications also work well with UI automation

testing tools, too. You can write test scripts that simulate user
interactions without needing to guess which HTML element
structures, CSS classes, or IDs the framework will generate, and
you do not have to worry about the structure changing
unexpectedly. 40
Key Benefits of ASP.NET Core

Powerful Routing System

 The style of uniform resource locators (URLs) has evolved as web
application technology has improved.

 URLs like this one:

/App_v2/User/Page.aspx?action=show
%20prop&prop_id=82742

are increasingly rare, replaced with a simpler, cleaner format

like this:

/to-rent/chicago/2303-silver-street
41
Key Benefits of ASP.NET Core

Reasons for caring about the structure of URLs

 First, search engines give weight to keywords found in a URL. A
search for “rent in Chicago” is much more likely to turn up the
simpler URL.

 Second, many web users are now savvy enough to understand a

URL and appreciate the option of navigating by typing it into their
browser’s address bar.

 Third, when someone understands the structure of a URL, they are

more likely to link to it, share it with a friend, or even read it aloud
over the phone.

 Fourth, it doesn’t expose the technical details, folder, and file

42
name structure of your application to the public Internet, so you
Key Benefits of ASP.NET Core

Powerful Routing System

 Clean URLs were hard to implement in earlier frameworks, but
ASP.NET Core MVC uses a feature known as URL routing to provide
clean URLs by default.

 This gives you control over your URL schema and its relationship
to your application, offering you the freedom to create a pattern of
URLs that is meaningful and useful to your users, without the need
to conform to a predefined pattern.

43
Key Benefits of ASP.NET Core

Modern API
 Microsoft’s .NET platform has evolved with each major release,
supporting—and even defining—the state-of-theart aspects of
modern programming.

 ASP.NET Core MVC is built for .NET Core, so its API can take full
advantage of language and runtime innovations familiar to C#
programmers, including the await keyword, extension methods,
lambda expressions, anonymous and dynamic types, and
Language Integrated Query (LINQ).

 Many of the ASP.NET Core MVC API methods and coding patterns
follow a cleaner, more expressive composition than was possible
with earlier platforms.
44
Key Benefits of ASP.NET Core

Cross-Platform
 Previous versions of ASP.NET were specific to Windows, requiring a
Windows desktop to write web applications and a Windows server
to deploy and run them. Microsoft made ASP.NET Core cross-
platform, both for development and for deployment. .NET Core is
available for different platforms—including Linux and OS X/macOS
—and is likely to be ported to others.

 Most ASP.NET Core MVC development is likely to be done using

Visual Studio for the immediate future, but Microsoft has also
created a cross-platform development tool called Visual Studio
Code, which means that ASP.NET Core MVC development is no
longer restricted to Windows.

45
Key Benefits of ASP.NET Core

Open Source
 Unlike previous Microsoft web development platforms, you are free
to download the source code for ASP. NET Core and ASP.NET Core
MVC and even modify and compile your own version of it.

 This is invaluable when your debugging trail leads into a system

component and you want to step into its code (and even read the
original programmers’ comments). It is also useful if you are
building an advanced component and want to see what
development possibilities exist or how the built-in components
actually work.

 You can download the ASP.NET Core and ASP.NET Core MVC source
code from https://github.com/aspnet .
46
Project Structure
Visual Studio Project Templates

 Visual Studio offers several ASP.NET Core templates:

 Empty
 Web API
 Web Application

 Different authentication methods can be chosen.

48
Visual Studio Project Templates

49
Visual Studio Project Templates

 The Empty project template contains the plumbing for ASP.NET

Core but doesn’t include the libraries or configuration required for
an MVC application.
 The Web API project template includes ASP.NET Core and MVC,
with a sample application that demonstrates how to receive and
process Ajax requests from clients.
 The Web Application project template includes ASP.NET Core and
MVC, with a sample application that demonstrates how to
generate HTML content.

 Note: The Web API and Web Application templates can be

configured with different schemes for authenticating users and
authorizing their access to the application.
50
Visual Studio Project Templates

 The templates are just different starting points into the same
functionality, and you can add whatever functionality you need to
projects created with any of the templates.

 So, the real difference between the project templates is the initial
set of libraries, configuration files, code, and content that Visual
Studio adds when it creates the project.

 Regardless of the template that you use to create a project, there

are some common folders and files that will appear. Some of the
items in a project have special roles that are hard-coded into
ASP.NET or MVC or one of the tools that Visual Studio provides
support for. Others are subject to naming conventions that are
used in most ASP.NET or MVC projects. 51
Visual Studio Project Structure

Folder or File Description

/Areas Areas are a way of partitioning a large application into smaller pieces.
/Dependencies The Dependencies item provides details of all the packages a project
relies on.
/Components This is where view component classes, which are used to display
selfcontained features such as shopping carts, are defined.
/Controllers This is where you put your controller classes. This is a convention. You
can put your controller classes anywhere you like, because they are all
compiled into the same assembly.

52
Visual Studio Project Structure

Folder or File Description

/Data This is where database context classes should be defined, but they are
also frequently defined in the Models folder.
/Migrations This is where details of database schemas are stored so that
deployment
databases can be updated.
/Models This is where you put your view model and domain model classes. This
is a convention. You can define your model classes anywhere in the
project or in a separate project.

53
Visual Studio Project Structure

Folder or File Description

/Views This directory holds views and partial views, usually grouped together
in folders named after the controller with which they are associated.
/Views/Shared This directory holds layouts and views that are not specific to a single
controller.

54
Visual Studio Project Structure

Folder or File Description

/Views/_ViewImports.cshtml This file is used to specify the namespaces that will be

included in Razor view files.
/Views/_ViewStart.cshtml This file is used to specify a default layout for the Razor
view engine.
/bower.json This file is hidden by default. It contains the list of
packages managed by the Bower package manager.
/project.json This file specifies some basic configuration options for the
project, including the NuGet packages it uses.
/Program.cs This class configures the hosting platform for the
application

55
Visual Studio Project Structure

Folder or File Description

/Startup.cs This class configures the application

/wwwroot This is where you put static content such as CSS files and
images. It is also where the Bower package manager
installs JavaScript and CSS packages

56
Convention Over Configuration

 There are two kinds of conventions in an MVC project:

 The first kind is just suggestions as to how you might like to
structure your project. For example, it is conventional to put the
third-party JavaScript and CSS packages you rely on in the
wwwroot/lib folder. This is where other MVC developers would
expect to find them and where the package manager will install
them. But you are free to rename the lib folder, or remove it
entirely and put your packages somewhere else. That would not
prevent MVC from running your application as long as the script
and link elements in your views refer to the location you settle
on.

57
Convention Over Configuration

 The other kind of convention arises from the principle of

convention over configuration , which was one of the main
selling points that made Ruby on Rails so popular. Convention
over configuration means that you don’t need to explicitly
configure associations between controllers and their views, for
example.

 You just follow a certain naming convention for your files, and
everything just works. There is less flexibility in changing your
project structure when dealing with this kind of convention.

58
Convention Over Configuration

 By following a certain naming convention, everything “works”.

 Principles
 avoid configuring things that can be inferred;
 all convention-based defaults can be overridden.

 Example:
 No need to explicitly configure associations between controllers and their
views;

59
Convention Over Configuration

 Three core directions:

 Controllers;
 Models;
 Views.

 Following common conventions and using a software design

pattern facilitates code understanding even in large applications.

60
Controller Conventions

 All controller classes end in “Controller” (ex: HomeController”);

 Controllers are referenced only by the first part in their names;

 New controller conventions can be created by implementing

IControllerFactory.

61
View Conventions

 Views and partial views should be located in the folder

/Views/ControllerName.
 ex: /Views/Home for the HomeController

 The default view for an action should be named after that method.
 ex: for an action Index, the view should be named Index.cshtml

 Choosing the right view:

 The default view will be used for: return View();
 A different view can be specified by name: return View(“Other”);

62
Layout Conventions

 Layout file names are prefixed with “_” (underscore);

 Layouts are placed in the folder /Views/Shared/;
 The default layout can be changed in _ViewStart.cshtml;
 Specific layouts can be defined for every view:

ex: @{Layout = “~Views/Shared/_OtherLayout.cshtml”; }

 Layouts can be disabled for a given view:

ex: @{Layout = null;}

63
A More Complex Project
Demo

https://github.com/liviucotfas/ase-web-a
nd-cloud-applications-security/

65
Thank you!