Download Full Version ebook - Visit ebookmeta.

com

Architect Modern Web Applications with ASP NET

Core and Azure Steve "Ardalis" Smith

https://ebookmeta.com/product/architect-modern-web-
applications-with-asp-net-core-and-azure-steve-ardalis-
smith/

OR CLICK HERE

DOWLOAD NOW

Discover More Ebook - Explore Now at ebookmeta.com

 Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Start reading on any device today!

Architect Modern Web Applications with ASP NET Core and

Azure Steve "Ardalis" Smith

https://ebookmeta.com/product/architect-modern-web-applications-with-
asp-net-core-and-azure-steve-ardalis-smith-2/

ebookmeta.com

ASP NET Core MVC 2 0 Cookbook Effective ways to build

modern interactive web applications with ASP NET Core MVC
2 0 1st Edition Engin Polat
https://ebookmeta.com/product/asp-net-core-mvc-2-0-cookbook-effective-
ways-to-build-modern-interactive-web-applications-with-asp-net-core-
mvc-2-0-1st-edition-engin-polat/
ebookmeta.com

Building Modern Web Applications with ASP NET Core Blazor

Learn how to use Blazor to create powerful responsive and
engaging web applications Brian Ding
https://ebookmeta.com/product/building-modern-web-applications-with-
asp-net-core-blazor-learn-how-to-use-blazor-to-create-powerful-
responsive-and-engaging-web-applications-brian-ding/
ebookmeta.com

I m Buffy and You re History Buffy the Vampire Slayer and

Contemporary Feminism Patricia Pender

https://ebookmeta.com/product/i-m-buffy-and-you-re-history-buffy-the-
vampire-slayer-and-contemporary-feminism-patricia-pender/

ebookmeta.com
Certified OpenStack Administrator Study Guide Get
Everything You Need for the COA Exam Certification Study
Companion Series 2nd Edition Andrey Markelov
https://ebookmeta.com/product/certified-openstack-administrator-study-
guide-get-everything-you-need-for-the-coa-exam-certification-study-
companion-series-2nd-edition-andrey-markelov/
ebookmeta.com

Post Conflict Monuments in Bosnia and Herzegovina

Unfinished Histories 1st Edition Uroš ■voro

https://ebookmeta.com/product/post-conflict-monuments-in-bosnia-and-
herzegovina-unfinished-histories-1st-edition-uros-cvoro/

ebookmeta.com

Polymer Composite Systems in Pipeline Repair Design

Manufacture Application and Environmental Impacts 1st
Edition Sanjay Mavinkere Rangappa (Editor)
https://ebookmeta.com/product/polymer-composite-systems-in-pipeline-
repair-design-manufacture-application-and-environmental-impacts-1st-
edition-sanjay-mavinkere-rangappa-editor/
ebookmeta.com

Clinical neuroanatomy Lange 29th Edition Stephen Waxman

https://ebookmeta.com/product/clinical-neuroanatomy-lange-29th-
edition-stephen-waxman/

ebookmeta.com

Abnormal Psychology (6th Canadian edition) Gordon L. Flett

https://ebookmeta.com/product/abnormal-psychology-6th-canadian-
edition-gordon-l-flett/

ebookmeta.com
Doing Critical Social Work Transformative Practices for
Social Justice 1st Edition Bob Pease Editor Sophie
Goldingay Editor Norah Hosken Editor Sharlene Nipperess
Editor
https://ebookmeta.com/product/doing-critical-social-work-
transformative-practices-for-social-justice-1st-edition-bob-pease-
editor-sophie-goldingay-editor-norah-hosken-editor-sharlene-nipperess-
editor/
ebookmeta.com
EDITION v5.0.1 - Updated to ASP.NET Core 5.0

Refer changelog for the book updates and community contributions.

PUBLISHED BY

Microsoft Developer Division, .NET, and Visual Studio product teams

A division of Microsoft Corporation

One Microsoft Way

Redmond, Washington 98052-6399

Copyright © 2021 by Microsoft Corporation

All rights reserved. No part of the contents of this book may be reproduced or transmitted in any
form or by any means without the written permission of the publisher.

This book is provided “as-is” and expresses the author’s views and opinions. The views, opinions, and
information expressed in this book, including URL and other Internet website references, may change
without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association
or connection is intended or should be inferred.

Microsoft and the trademarks listed at https://www.microsoft.com on the “Trademarks” webpage are
trademarks of the Microsoft group of companies.

Mac and macOS are trademarks of Apple Inc.

The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.

All other marks and logos are property of their respective owners.

Author:

Steve “ardalis” Smith - Software Architect and Trainer - Ardalis.com

Editors:

Maira Wenzel

Action links
• This e-book is also available in a PDF format (English version only) Download

• Clone/Fork the reference application eShopOnWeb on GitHub

Introduction
.NET 5 and ASP.NET Core offer several advantages over traditional .NET development. You should use
.NET 5 for your server applications if some or all of the following are important to your application’s
success:

• Cross-platform support.
• Use of microservices.

• Use of Docker containers.

• High performance and scalability requirements.

• Side-by-side versioning of .NET versions by application on the same server.

Traditional .NET applications can and do support many of these requirements, but ASP.NET Core and
.NET 5 have been optimized to offer improved support for the above scenarios.

More and more organizations are choosing to host their web applications in the cloud using services
like Microsoft Azure. You should consider hosting your application in the cloud if the following are
important to your application or organization:

• Reduced investment in data center costs (hardware, software, space, utilities, server
management, etc.)

• Flexible pricing (pay based on usage, not for idle capacity).

• Extreme reliability.

• Improved app mobility; easily change where and how your app is deployed.

• Flexible capacity; scale up or down based on actual needs.

Building web applications with ASP.NET Core, hosted in Azure, offers many competitive advantages
over traditional alternatives. ASP.NET Core is optimized for modern web application development
practices and cloud hosting scenarios. In this guide, you’ll learn how to architect your ASP.NET Core
applications to best take advantage of these capabilities.

Version
This guide has been revised to cover .NET 5.0 version along with many additional updates related to
the same “wave” of technologies (that is, Azure and additional third-party technologies) coinciding in
time with the .NET 5.0 release. That’s why the book version has also been updated to version 5.0.

Purpose
This guide provides end-to-end guidance on building monolithic web applications using ASP.NET
Core and Azure. In this context, “monolithic” refers to the fact that these applications are deployed as
a single unit, not as a collection of interacting services and applications.

This guide is complementary to “.NET Microservices. Architecture for Containerized .NET Applications”,
which focuses more on Docker, microservices, and deployment of containers to host enterprise
applications.

.NET Microservices. Architecture for Containerized .NET Applications

• e-book
https://aka.ms/MicroservicesEbook
• Sample Application
https://aka.ms/microservicesarchitecture

Who should use this guide

The audience for this guide is mainly developers, development leads, and architects who are
interested in building modern web applications using Microsoft technologies and services in the
cloud.

A secondary audience is technical decision makers who are already familiar ASP.NET or Azure and are
looking for information on whether it makes sense to upgrade to ASP.NET Core for new or existing
projects.

How you can use this guide

This guide has been condensed into a relatively small document that focuses on building web
applications with modern .NET technologies and Azure. As such, it can be read in its entirety to
provide a foundation of understanding such applications and their technical considerations. The
guide, along with its sample application, can also serve as a starting point or reference. Use the
associated sample application as a template for your own applications, or to see how you might
organize your application’s component parts. Refer back to the guide’s principles and coverage of
architecture and technology options and decision considerations when you’re weighing these choices
for your own application.

Feel free to forward this guide to your team to help ensure a common understanding of these
considerations and opportunities. Having everybody working from a common set of terminology and
underlying principles helps ensure consistent application of architectural patterns and practices.

References
• Choosing between .NET 5 and .NET Framework for server apps
https://docs.microsoft.com/dotnet/standard/choosing-core-framework-server
Contents
Characteristics of Modern Web Applications ....................................................................... 1
Reference application: eShopOnWeb .............................................................................................................................. 1

Reference Application ....................................................................................................................................................... 2

Cloud-hosted and scalable .................................................................................................................................................. 2

Cross platform ........................................................................................................................................................................... 2

Modular and loosely coupled ............................................................................................................................................. 3

Easily tested with automated tests ................................................................................................................................... 3

Traditional and SPA behaviors supported ..................................................................................................................... 3

Simple development and deployment ............................................................................................................................ 4

Traditional ASP.NET and Web Forms ............................................................................................................................... 4

Blazor ............................................................................................................................................................................................ 4

References – Modern Web Applications ................................................................................................................... 4

Choose Between Traditional Web Apps and Single Page Apps (SPAs) ............................. 6
Blazor ............................................................................................................................................................................................ 7

When to choose traditional web apps ............................................................................................................................ 7

When to choose SPAs ............................................................................................................................................................ 8

References – SPA Frameworks ....................................................................................................................................... 8

When to choose Blazor ......................................................................................................................................................... 9

Decision table ............................................................................................................................................................................ 9

Architectural principles......................................................................................................... 10
Common design principles ............................................................................................................................................... 10

Separation of concerns .................................................................................................................................................. 10

Encapsulation ..................................................................................................................................................................... 10

Dependency inversion .................................................................................................................................................... 11

Explicit dependencies ..................................................................................................................................................... 12

Single responsibility ........................................................................................................................................................ 13

Don’t repeat yourself (DRY) ......................................................................................................................................... 13

Persistence ignorance .................................................................................................................................................... 13

i Contents
 Bounded contexts ............................................................................................................................................................ 14

Additional resources ............................................................................................................................................................ 14

Common web application architectures ............................................................................. 15

What is a monolithic application? .................................................................................................................................. 15

All-in-one applications ....................................................................................................................................................... 15

What are layers? .................................................................................................................................................................... 16

Traditional “N-Layer” architecture applications ........................................................................................................ 17

Clean architecture ................................................................................................................................................................. 21

Organizing code in Clean Architecture ................................................................................................................... 26

Monolithic applications and containers ....................................................................................................................... 27

Monolithic application deployed as a container ................................................................................................. 29

Docker support ...................................................................................................................................................................... 31

Troubleshooting Docker problems ........................................................................................................................... 32

References – Common web architectures .............................................................................................................. 32

Common client-side web technologies ............................................................................... 33

HTML.......................................................................................................................................................................................... 33

CSS .............................................................................................................................................................................................. 33

CSS preprocessors ........................................................................................................................................................... 34

JavaScript ................................................................................................................................................................................. 35

Legacy web apps with jQuery ..................................................................................................................................... 35

jQuery vs a SPA Framework ......................................................................................................................................... 35

Angular SPAs...................................................................................................................................................................... 36

React ...................................................................................................................................................................................... 37

Vue ......................................................................................................................................................................................... 37

Blazor WebAssembly ...................................................................................................................................................... 38

Choosing a SPA Framework ......................................................................................................................................... 39

References – Client Web Technologies ................................................................................................................... 39

Develop ASP.NET Core MVC apps ....................................................................................... 40

MVC and Razor Pages ......................................................................................................................................................... 40

Why Razor Pages?............................................................................................................................................................ 41

When to use MVC ............................................................................................................................................................ 41

ii Contents
 Mapping requests to responses ..................................................................................................................................... 41

Keeping controllers under control ............................................................................................................................ 43

References – Mapping Requests to Responses ................................................................................................... 45

Working with dependencies ............................................................................................................................................. 45

Declare your dependencies .......................................................................................................................................... 46

Structuring the application ............................................................................................................................................... 47

Feature organization ....................................................................................................................................................... 48

APIs and Blazor applications........................................................................................................................................ 49

Cross-cutting concerns .................................................................................................................................................. 50

References – Structuring applications ..................................................................................................................... 52

Security ..................................................................................................................................................................................... 53

Identity ................................................................................................................................................................................. 53

Authentication ................................................................................................................................................................... 55

References – Authentication ........................................................................................................................................ 56

Authorization ..................................................................................................................................................................... 57

References – Security ...................................................................................................................................................... 59

Client communication ......................................................................................................................................................... 59

References – Client Communication ........................................................................................................................ 60

Domain-driven design – Should you apply it? .......................................................................................................... 60

When should you apply DDD ...................................................................................................................................... 61

When shouldn’t you apply DDD ................................................................................................................................ 61

References – Domain-Driven Design ....................................................................................................................... 62

Deployment............................................................................................................................................................................. 62

References – Deployment ............................................................................................................................................. 63

Working with Data in ASP.NET Core Apps ......................................................................... 64

Entity Framework Core (for relational databases) .................................................................................................... 64

The DbContext .................................................................................................................................................................. 64

Configuring EF Core ........................................................................................................................................................ 65

Fetching and storing Data ............................................................................................................................................ 66

Fetching related data ...................................................................................................................................................... 67

Encapsulating data .......................................................................................................................................................... 68

Resilient connections ...................................................................................................................................................... 69

iii Contents
 References – Entity Framework Core ........................................................................................................................ 71

EF Core or micro-ORM? ..................................................................................................................................................... 71

SQL or NoSQL ........................................................................................................................................................................ 72

Azure Cosmos DB ................................................................................................................................................................. 73

Other persistence options ................................................................................................................................................. 74

Caching ..................................................................................................................................................................................... 75

ASP.NET Core response caching ................................................................................................................................ 75

Data caching ...................................................................................................................................................................... 76

Getting data to Blazor WebAssembly apps ................................................................................................................ 78

Test ASP.NET Core MVC apps .............................................................................................. 80

Kinds of automated tests ................................................................................................................................................... 80

Unit tests .............................................................................................................................................................................. 80

Integration tests................................................................................................................................................................ 80

Functional tests ................................................................................................................................................................. 81

Testing Pyramid ................................................................................................................................................................ 81

What to test ........................................................................................................................................................................ 82

Organizing test projects ..................................................................................................................................................... 83

Test naming ........................................................................................................................................................................ 84

Unit testing ASP.NET Core apps ..................................................................................................................................... 85

Integration testing ASP.NET Core apps ....................................................................................................................... 87

Functional testing ASP.NET Core apps ......................................................................................................................... 87

References – Test ASP.NET Core MVC apps .......................................................................................................... 90

Development process for Azure .......................................................................................... 91

Vision ......................................................................................................................................................................................... 91

Development environment for ASP.NET Core apps ............................................................................................... 91

Development tools choices: IDE or editor .............................................................................................................. 91

Development workflow for Azure-hosted ASP.NET Core apps .......................................................................... 92

Initial setup ......................................................................................................................................................................... 92

Workflow for developing Azure-hosted ASP.NET Core applications .......................................................... 93

References ............................................................................................................................................................................... 95

Azure hosting recommendations for ASP.NET Core web apps ........................................ 96

iv Contents
 Web applications .................................................................................................................................................................. 96

App Service Web Apps .................................................................................................................................................. 96

App Service Web Apps for Containers .................................................................................................................... 98

Azure Kubernetes Service ........................................................................................................................................... 101

Azure Virtual Machines ................................................................................................................................................ 102

Logical processes ................................................................................................................................................................ 102

Data .......................................................................................................................................................................................... 102

Architecture recommendations..................................................................................................................................... 103

v Contents
 CHAPTER 1
Characteristics of Modern
Web Applications
“… with proper design, the features come cheaply. This approach is arduous, but continues to
succeed.”
- Dennis Ritchie

Modern web applications have higher user expectations and greater demands than ever before.
Today’s web apps are expected to be available 24/7 from anywhere in the world, and usable from
virtually any device or screen size. Web applications must be secure, flexible, and scalable to meet
spikes in demand. Increasingly, complex scenarios should be handled by rich user experiences built on
the client using JavaScript, and communicating efficiently through web APIs.

ASP.NET Core is optimized for modern web applications and cloud-based hosting scenarios. Its
modular design enables applications to depend on only those features they actually use, improving
application security and performance while reducing hosting resource requirements.

Reference application: eShopOnWeb

This guidance includes a reference application, eShopOnWeb, that demonstrates some of the
principles and recommendations. The application is a simple online store, which supports browsing
through a catalog of shirts, coffee mugs, and other marketing items. The reference application is
deliberately simple in order to make it easy to understand.

1 CHAPTER 1 | Characteristics of Modern Web Applications

Figure 2-1. eShopOnWeb

Reference Application
• eShopOnWeb
https://github.com/dotnet/eShopOnWeb

Cloud-hosted and scalable

ASP.NET Core is optimized for the cloud (public cloud, private cloud, any cloud) because it is low-
memory and high-throughput. The smaller footprint of ASP.NET Core applications means you can
host more of them on the same hardware, and you pay for fewer resources when using pay-as-you-
go cloud hosting services. The higher-throughput means you can serve more customers from an
application given the same hardware, further reducing the need to invest in servers and hosting
infrastructure.

Cross platform
ASP.NET Core is cross-platform and can run on Linux, macOS, and Windows. This capability opens up
many new options for both the development and deployment of apps built with ASP.NET Core.

2 CHAPTER 1 | Characteristics of Modern Web Applications

Docker containers - both Linux and Windows - can host ASP.NET Core applications, allowing them to
take advantage of the benefits of containers and microservices.

Modular and loosely coupled

NuGet packages are first-class citizens in .NET Core, and ASP.NET Core apps are composed of many
libraries through NuGet. This granularity of functionality helps ensure apps only depend on and
deploy functionality they actually require, reducing their footprint and security vulnerability surface
area.

ASP.NET Core also fully supports dependency injection, both internally and at the application level.
Interfaces can have multiple implementations that can be swapped out as needed. Dependency
injection allows apps to loosely couple to those interfaces, rather than specific implementations,
making them easier to extend, maintain, and test.

Easily tested with automated tests

ASP.NET Core applications support unit testing, and their loose coupling and support for dependency
injection makes it easy to swap infrastructure concerns with fake implementations for test purposes.
ASP.NET Core also ships with a TestServer that can be used to host apps in memory. Functional tests
can then make requests to this in-memory server, exercising the full application stack (including
middleware, routing, model binding, filters, etc.) and receiving a response, all in a fraction of the time
it would take to host the app on a real server and make requests through the network layer. These
tests are especially easy to write, and valuable, for APIs, which are increasingly important in modern
web applications.

Traditional and SPA behaviors supported

Traditional web applications have involved little client-side behavior, but instead have relied on the
server for all navigation, queries, and updates the app might need to make. Each new operation made
by the user would be translated into a new web request, with the result being a full page reload in the
end user’s browser. Classic Model-View-Controller (MVC) frameworks typically follow this approach,
with each new request corresponding to a different controller action, which in turn would work with a
model and return a view. Some individual operations on a given page might be enhanced with AJAX
(Asynchronous JavaScript and XML) functionality, but the overall architecture of the app used many
different MVC views and URL endpoints. In addition, ASP.NET Core MVC also supports Razor Pages, a
simpler way to organize MVC-style pages.

Single Page Applications (SPAs), by contrast, involve very few dynamically generated server-side page
loads (if any). Many SPAs are initialized within a static HTML file that loads the necessary JavaScript
libraries to start and run the app. These apps make heavy usage of web APIs for their data needs and
can provide much richer user experiences.

3 CHAPTER 1 | Characteristics of Modern Web Applications

Many web applications involve a combination of traditional web application behavior (typically for
content) and SPAs (for interactivity). ASP.NET Core supports both MVC (Views or Page based) and web
APIs in the same application, using the same set of tools and underlying framework libraries.

Simple development and deployment

ASP.NET Core applications can be written using simple text editors and command-line interfaces, or
full-featured development environments like Visual Studio. Monolithic applications are typically
deployed to a single endpoint. Deployments can easily be automated to occur as part of a continuous
integration (CI) and continuous delivery (CD) pipeline. In addition to traditional CI/CD tools, Microsoft
Azure has integrated support for git repositories and can automatically deploy updates as they are
made to a specified git branch or tag. Azure DevOps provides a full-featured CI/CD build and
deployment pipeline, and GitHub Actions provide another option for projects hosted there.

Traditional ASP.NET and Web Forms

In addition to ASP.NET Core, traditional ASP.NET 4.x continues to be a robust and reliable platform for
building web applications. ASP.NET supports MVC and Web API development models, as well as Web
Forms, which is well suited to rich page-based application development and features a rich third-party
component ecosystem. Microsoft Azure has great longstanding support for ASP.NET 4.x applications,
and many developers are familiar with this platform.

Blazor
Blazor is included with ASP.NET Core 3.0 and later. It provides a new mechanism for building rich
interactive web client applications using Razor, C#, and ASP.NET Core. It offers another solution to
consider when developing modern web applications. There are two versions of Blazor to consider:
server-side and client-side.

Server-side Blazor was released in 2019 with ASP.NET Core 3.0. As its name implies, it runs on the
server, rendering changes to the client document back to the browser over the network. Server-side
Blazor provides a rich client experience without requiring client-side JavaScript and without requiring
separate page loads for each client page interaction. Changes in the loaded page are requested from
and processed by the server and then sent back to the client using SignalR.

Client-side Blazor released in May 2020 eliminates the need to render changes on the server. Instead,
it leverages WebAssembly to run .NET code within the client. The client can still make API calls to the
server if needed to request data, but all client-side behavior runs in the client via WebAssembly, which
is already supported by all major browsers and is just a JavaScript library.

References – Modern Web Applications

• Introduction to ASP.NET Core
https://docs.microsoft.com/aspnet/core/

4 CHAPTER 1 | Characteristics of Modern Web Applications

• Testing in ASP.NET Core
https://docs.microsoft.com/aspnet/core/testing/
• Blazor - Get Started
https://blazor.net/docs/get-started.html

5 CHAPTER 1 | Characteristics of Modern Web Applications

 CHAPTER 2
Choose Between
Traditional Web Apps and
Single Page Apps (SPAs)
“Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in
JavaScript.”
- Jeff Atwood

There are two general approaches to building web applications today: traditional web applications
that perform most of the application logic on the server, and single-page applications (SPAs) that
perform most of the user interface logic in a web browser, communicating with the web server
primarily using web APIs. A hybrid approach is also possible, the simplest being host one or more rich
SPA-like subapplications within a larger traditional web application.

Use traditional web applications when:

• Your application’s client-side requirements are simple or even read-only.

• Your application needs to function in browsers without JavaScript support.

• Your team is unfamiliar with JavaScript or TypeScript development techniques.

Use a SPA when:

• Your application must expose a rich user interface with many features.

• Your team is familiar with JavaScript, TypeScript, or Blazor WebAssembly development.

• Your application must already expose an API for other (internal or public) clients.

Additionally, SPA frameworks require greater architectural and security expertise. They experience
greater churn due to frequent updates and new frameworks than traditional web applications.
Configuring automated build and deployment processes and utilizing deployment options like
containers may be more difficult with SPA applications than traditional web apps.

Improvements in user experience made possible by the SPA approach must be weighed against these
considerations.

6 CHAPTER 2 | Choose Between Traditional Web Apps and Single Page Apps (SPAs)
Blazor
ASP.NET Core includes a model for building rich, interactive, and composable user interfaces called
Blazor. Blazor server-side allows developers to build UI with C# and Razor on the server and for the UI
to be interactively connected to the browser in real-time using a persistent SignalR connection. Blazor
WebAssembly introduces another option for Blazor apps, allowing them to run in the browser using
WebAssembly. Because it’s real .NET running on WebAssembly, you can reuse code and libraries from
server-side parts of your application.

Blazor provides a new, third option to consider when evaluating whether to build a purely server-
rendered web application or a SPA. You can build rich, SPA-like client-side behaviors using Blazor,
without the need for significant JavaScript development. Blazor applications can call APIs to request
data or perform server-side operations. They can interoperate with JavaScript where necessary to take
advantage of JavaScript libraries and frameworks.

Consider building your web application with Blazor when:

• Your application must expose a rich user interface

• Your team is more comfortable with .NET development than JavaScript or TypeScript
development

If you have an existing web forms application you’re considering migrating to .NET Core or the latest
.NET, you may wish to review the free e-book, Blazor for Web Forms Developers to see whether it
makes sense to consider migrating it to Blazor.

For more information about Blazor, see Get started with Blazor.

When to choose traditional web apps

The following section is a more detailed explanation of the previously stated reasons for picking
traditional web applications.

Your application has simple, possibly read-only, client-side requirements

Many web applications are primarily consumed in a read-only fashion by the vast majority of their
users. Read-only (or read-mostly) applications tend to be much simpler than those applications that
maintain and manipulate a great deal of state. For example, a search engine might consist of a single
entry point with a textbox and a second page for displaying search results. Anonymous users can
easily make requests, and there is little need for client-side logic. Likewise, a blog or content
management system’s public-facing application usually consists mainly of content with little client-
side behavior. Such applications are easily built as traditional server-based web applications, which
perform logic on the web server and render HTML to be displayed in the browser. The fact that each
unique page of the site has its own URL that can be bookmarked and indexed by search engines (by
default, without having to add this functionality as a separate feature of the application) is also a clear
benefit in such scenarios.

Your application needs to function in browsers without JavaScript support

7 CHAPTER 2 | Choose Between Traditional Web Apps and Single Page Apps (SPAs)
Web applications that need to function in browsers with limited or no JavaScript support should be
written using traditional web app workflows (or at least be able to fall back to such behavior). SPAs
require client-side JavaScript in order to function; if it’s not available, SPAs are not a good choice.

Your team is unfamiliar with JavaScript or TypeScript development techniques

If your team is unfamiliar with JavaScript or TypeScript, but is familiar with server-side web application
development, then they will probably be able to deliver a traditional web app more quickly than a
SPA. Unless learning to program SPAs is a goal, or the user experience afforded by a SPA is required,
traditional web apps are a more productive choice for teams who are already familiar with building
them.

When to choose SPAs

The following section is a more detailed explanation of when to choose a Single Page Applications
style of development for your web app.

Your application must expose a rich user interface with many features

SPAs can support rich client-side functionality that doesn’t require reloading the page as users take
actions or navigate between areas of the app. SPAs can load more quickly, fetching data in the
background, and individual user actions are more responsive since full page reloads are rare. SPAs can
support incremental updates, saving partially completed forms or documents without the user having
to click a button to submit a form. SPAs can support rich client-side behaviors, such as drag-and-drop,
much more readily than traditional applications. SPAs can be designed to run in a disconnected mode,
making updates to a client-side model that are eventually synchronized back to the server once a
connection is re-established. Choose a SPA-style application if your app’s requirements include rich
functionality that goes beyond what typical HTML forms offer.

Frequently, SPAs need to implement features that are built into traditional web apps, such as
displaying a meaningful URL in the address bar reflecting the current operation (and allowing users to
bookmark or deep link to this URL to return to it). SPAs also should allow users to use the browser’s
back and forward buttons with results that won’t surprise them.

Your team is familiar with JavaScript and/or TypeScript development

Writing SPAs requires familiarity with JavaScript and/or TypeScript and client-side programming
techniques and libraries. Your team should be competent in writing modern JavaScript using a SPA
framework like Angular.

References – SPA Frameworks

• Angular: https://angular.io
• React: https://reactjs.org/
• Vue.js: https://vuejs.org/
Your application must already expose an API for other (internal or public) clients

8 CHAPTER 2 | Choose Between Traditional Web Apps and Single Page Apps (SPAs)
If you’re already supporting a web API for use by other clients, it may require less effort to create a
SPA implementation that leverages these APIs rather than reproducing the logic in server-side form.
SPAs make extensive use of web APIs to query and update data as users interact with the application.

When to choose Blazor

The following section is a more detailed explanation of when to choose Blazor for your web app.

Your application must expose a rich user interface

Like JavaScript-based SPAs, Blazor applications can support rich client behavior without page reloads.
These applications are more responsive to users, fetching only the data (or HTML) required to respond
to a given user interaction. Designed properly, server-side Blazor apps can be configured to run as
client-side Blazor apps with minimal changes once this feature is supported.

Your team is more comfortable with .NET development than JavaScript or TypeScript
development

Many developers are more productive with .NET and Razor than with client-side languages like
JavaScript or TypeScript. Since the server-side of the application is already being developed with .NET,
using Blazor ensures every .NET developer on the team can understand and potentially build the
behavior of the front end of the application.

Decision table
The following decision table summarizes some of the basic factors to consider when choosing
between a traditional web application, a SPA, or a Blazor app.

Traditional Web Single Page

Factor App Application Blazor App
Required Team Familiarity with Minimal Required Minimal
JavaScript/TypeScript
Support Browsers without Scripting Supported Not Supported Supported
Minimal Client-Side Application Behavior Well-Suited Overkill Viable
Rich, Complex User Interface Limited Well-Suited Well-
Requirements Suited

9 CHAPTER 2 | Choose Between Traditional Web Apps and Single Page Apps (SPAs)
 CHAPTER 3
Architectural principles
“If builders built buildings the way programmers wrote programs, then the first woodpecker that
came along would destroy civilization.”
- Gerald Weinberg

You should architect and design software solutions with maintainability in mind. The principles
outlined in this section can help guide you toward architectural decisions that will result in clean,
maintainable applications. Generally, these principles will guide you toward building applications out
of discrete components that are not tightly coupled to other parts of your application, but rather
communicate through explicit interfaces or messaging systems.

Common design principles

Separation of concerns
A guiding principle when developing is Separation of Concerns. This principle asserts that software
should be separated based on the kinds of work it performs. For instance, consider an application that
includes logic for identifying noteworthy items to display to the user, and which formats such items in
a particular way to make them more noticeable. The behavior responsible for choosing which items to
format should be kept separate from the behavior responsible for formatting the items, since these
behaviors are separate concerns that are only coincidentally related to one another.

Architecturally, applications can be logically built to follow this principle by separating core business
behavior from infrastructure and user-interface logic. Ideally, business rules and logic should reside in
a separate project, which should not depend on other projects in the application. This separation
helps ensure that the business model is easy to test and can evolve without being tightly coupled to
low-level implementation details. Separation of concerns is a key consideration behind the use of
layers in application architectures.

Encapsulation
Different parts of an application should use encapsulation to insulate them from other parts of the
application. Application components and layers should be able to adjust their internal implementation
without breaking their collaborators as long as external contracts are not violated. Proper use of
encapsulation helps achieve loose coupling and modularity in application designs, since objects and
packages can be replaced with alternative implementations so long as the same interface is
maintained.

10 CHAPTER 3 | Architectural principles

In classes, encapsulation is achieved by limiting outside access to the class’s internal state. If an
outside actor wants to manipulate the state of the object, it should do so through a well-defined
function (or property setter), rather than having direct access to the private state of the object.
Likewise, application components and applications themselves should expose well-defined interfaces
for their collaborators to use, rather than allowing their state to be modified directly. This approach
frees the application’s internal design to evolve over time without worrying that doing so will break
collaborators, so long as the public contracts are maintained.

Dependency inversion
The direction of dependency within the application should be in the direction of abstraction, not
implementation details. Most applications are written such that compile-time dependency flows in the
direction of runtime execution, producing a direct dependency graph. That is, if class A calls a method
of class B and class B calls a method of class C, then at compile time class A will depend on class B,
and class B will depend on class C, as shown in Figure 4-1.

Figure 4-1. Direct dependency graph.

11 CHAPTER 3 | Architectural principles

Applying the dependency inversion principle allows A to call methods on an abstraction that B
implements, making it possible for A to call B at runtime, but for B to depend on an interface
controlled by A at compile time (thus, inverting the typical compile-time dependency). At run time, the
flow of program execution remains unchanged, but the introduction of interfaces means that different
implementations of these interfaces can easily be plugged in.

Figure 4-2. Inverted dependency graph.

Dependency inversion is a key part of building loosely coupled applications, since implementation
details can be written to depend on and implement higher-level abstractions, rather than the other
way around. The resulting applications are more testable, modular, and maintainable as a result. The
practice of dependency injection is made possible by following the dependency inversion principle.

Explicit dependencies
Methods and classes should explicitly require any collaborating objects they need in order to
function correctly. Class constructors provide an opportunity for classes to identify the things they
need in order to be in a valid state and to function properly. If you define classes that can be
constructed and called, but that will only function properly if certain global or infrastructure
components are in place, these classes are being dishonest with their clients. The constructor contract
is telling the client that it only needs the things specified (possibly nothing if the class is just using a
parameterless constructor), but then at runtime it turns out the object really did need something else.

By following the explicit dependencies principle, your classes and methods are being honest with their
clients about what they need in order to function. Following the principle makes your code more self-
documenting and your coding contracts more user-friendly, since users will come to trust that as long
as they provide what’s required in the form of method or constructor parameters, the objects they’re
working with will behave correctly at run time.

12 CHAPTER 3 | Architectural principles

Single responsibility
The single responsibility principle applies to object-oriented design, but can also be considered as an
architectural principle similar to separation of concerns. It states that objects should have only one
responsibility and that they should have only one reason to change. Specifically, the only situation in
which the object should change is if the manner in which it performs its one responsibility must be
updated. Following this principle helps to produce more loosely coupled and modular systems, since
many kinds of new behavior can be implemented as new classes, rather than by adding additional
responsibility to existing classes. Adding new classes is always safer than changing existing classes,
since no code yet depends on the new classes.

In a monolithic application, we can apply the single responsibility principle at a high level to the layers
in the application. Presentation responsibility should remain in the UI project, while data access
responsibility should be kept within an infrastructure project. Business logic should be kept in the
application core project, where it can be easily tested and can evolve independently from other
responsibilities.

When this principle is applied to application architecture and taken to its logical endpoint, you get
microservices. A given microservice should have a single responsibility. If you need to extend the
behavior of a system, it’s usually better to do it by adding additional microservices, rather than by
adding responsibility to an existing one.

Learn more about microservices architecture

Don’t repeat yourself (DRY)

The application should avoid specifying behavior related to a particular concept in multiple places as
this practice is a frequent source of errors. At some point, a change in requirements will require
changing this behavior. It’s likely that at least one instance of the behavior will fail to be updated, and
the system will behave inconsistently.

Rather than duplicating logic, encapsulate it in a programming construct. Make this construct the
single authority over this behavior, and have any other part of the application that requires this
behavior use the new construct.

Note

Avoid binding together behavior that is only coincidentally repetitive. For example, just because two
different constants both have the same value, that doesn’t mean you should have only one constant, if
conceptually they’re referring to different things.

Persistence ignorance
Persistence ignorance (PI) refers to types that need to be persisted, but whose code is unaffected by
the choice of persistence technology. Such types in .NET are sometimes referred to as Plain Old CLR
Objects (POCOs), because they do not need to inherit from a particular base class or implement a
particular interface. Persistence ignorance is valuable because it allows the same business model to be
persisted in multiple ways, offering additional flexibility to the application. Persistence choices might
change over time, from one database technology to another, or additional forms of persistence might
13 CHAPTER 3 | Architectural principles
be required in addition to whatever the application started with (for example, using a Redis cache or
Azure Cosmos DB in addition to a relational database).

Some examples of violations of this principle include:

• A required base class.

• A required interface implementation.

• Classes responsible for saving themselves (such as the Active Record pattern).

• Required parameterless constructor.

• Properties requiring virtual keyword.

• Persistence-specific required attributes.

The requirement that classes have any of the above features or behaviors adds coupling between the
types to be persisted and the choice of persistence technology, making it more difficult to adopt new
data access strategies in the future.

Bounded contexts
Bounded contexts are a central pattern in Domain-Driven Design. They provide a way of tackling
complexity in large applications or organizations by breaking it up into separate conceptual modules.
Each conceptual module then represents a context that is separated from other contexts (hence,
bounded), and can evolve independently. Each bounded context should ideally be free to choose its
own names for concepts within it, and should have exclusive access to its own persistence store.

At a minimum, individual web applications should strive to be their own bounded context, with their
own persistence store for their business model, rather than sharing a database with other applications.
Communication between bounded contexts occurs through programmatic interfaces, rather than
through a shared database, which allows for business logic and events to take place in response to
changes that take place. Bounded contexts map closely to microservices, which also are ideally
implemented as their own individual bounded contexts.

Additional resources
• JAVA Design Patterns: Principles
• Bounded Context

14 CHAPTER 3 | Architectural principles

 CHAPTER 4
Common web application
architectures
“If you think good architecture is expensive, try bad architecture.” - Brian Foote and Joseph Yoder

Most traditional .NET applications are deployed as single units corresponding to an executable or a
single web application running within a single IIS appdomain. This approach is the simplest
deployment model and serves many internal and smaller public applications very well. However, even
given this single unit of deployment, most non-trivial business applications benefit from some logical
separation into several layers.

What is a monolithic application?

A monolithic application is one that is entirely self-contained, in terms of its behavior. It may interact
with other services or data stores in the course of performing its operations, but the core of its
behavior runs within its own process and the entire application is typically deployed as a single unit. If
such an application needs to scale horizontally, typically the entire application is duplicated across
multiple servers or virtual machines.

All-in-one applications
The smallest possible number of projects for an application architecture is one. In this architecture, the
entire logic of the application is contained in a single project, compiled to a single assembly, and
deployed as a single unit.

A new ASP.NET Core project, whether created in Visual Studio or from the command line, starts out as
a simple “all-in-one” monolith. It contains all of the behavior of the application, including
presentation, business, and data access logic. Figure 5-1 shows the file structure of a single-project
app.

15 CHAPTER 4 | Common web application architectures

Figure 5-1. A single project ASP.NET Core app.

In a single project scenario, separation of concerns is achieved through the use of folders. The default
template includes separate folders for MVC pattern responsibilities of Models, Views, and Controllers,
as well as additional folders for Data and Services. In this arrangement, presentation details should be
limited as much as possible to the Views folder, and data access implementation details should be
limited to classes kept in the Data folder. Business logic should reside in services and classes within
the Models folder.

Although simple, the single-project monolithic solution has some disadvantages. As the project’s size
and complexity grows, the number of files and folders will continue to grow as well. User interface (UI)
concerns (models, views, controllers) reside in multiple folders, which aren’t grouped together
alphabetically. This issue only gets worse when additional UI-level constructs, such as Filters or
ModelBinders, are added in their own folders. Business logic is scattered between the Models and
Services folders, and there’s no clear indication of which classes in which folders should depend on
which others. This lack of organization at the project level frequently leads to spaghetti code.

To address these issues, applications often evolve into multi-project solutions, where each project is
considered to reside in a particular layer of the application.

What are layers?

As applications grow in complexity, one way to manage that complexity is to break up the application
according to its responsibilities or concerns. This approach follows the separation of concerns
principle and can help keep a growing codebase organized so that developers can easily find where
certain functionality is implemented. Layered architecture offers a number of advantages beyond just
code organization, though.

16 CHAPTER 4 | Common web application architectures

By organizing code into layers, common low-level functionality can be reused throughout the
application. This reuse is beneficial because it means less code needs to be written and because it can
allow the application to standardize on a single implementation, following the don’t repeat yourself
(DRY) principle.

With a layered architecture, applications can enforce restrictions on which layers can communicate
with other layers. This architecture helps to achieve encapsulation. When a layer is changed or
replaced, only those layers that work with it should be impacted. By limiting which layers depend on
which other layers, the impact of changes can be mitigated so that a single change doesn’t impact the
entire application.

Layers (and encapsulation) make it much easier to replace functionality within the application. For
example, an application might initially use its own SQL Server database for persistence, but later could
choose to use a cloud-based persistence strategy, or one behind a web API. If the application has
properly encapsulated its persistence implementation within a logical layer, that SQL Server-specific
layer could be replaced by a new one implementing the same public interface.

In addition to the potential of swapping out implementations in response to future changes in

requirements, application layers can also make it easier to swap out implementations for testing
purposes. Instead of having to write tests that operate against the real data layer or UI layer of the
application, these layers can be replaced at test time with fake implementations that provide known
responses to requests. This approach typically makes tests much easier to write and much faster to
run when compared to running tests against the application’s real infrastructure.

Logical layering is a common technique for improving the organization of code in enterprise software
applications, and there are several ways in which code can be organized into layers.

Note

Layers represent logical separation within the application. In the event that application logic is
physically distributed to separate servers or processes, these separate physical deployment targets are
referred to as tiers. It’s possible, and quite common, to have an N-Layer application that is deployed
to a single tier.

Traditional “N-Layer” architecture applications

The most common organization of application logic into layers is shown in Figure 5-2.

17 CHAPTER 4 | Common web application architectures

Figure 5-2. Typical application layers.

These layers are frequently abbreviated as UI, BLL (Business Logic Layer), and DAL (Data Access Layer).
Using this architecture, users make requests through the UI layer, which interacts only with the BLL.
The BLL, in turn, can call the DAL for data access requests. The UI layer shouldn’t make any requests to
the DAL directly, nor should it interact with persistence directly through other means. Likewise, the BLL
should only interact with persistence by going through the DAL. In this way, each layer has its own
well-known responsibility.

One disadvantage of this traditional layering approach is that compile-time dependencies run from
the top to the bottom. That is, the UI layer depends on the BLL, which depends on the DAL. This
means that the BLL, which usually holds the most important logic in the application, is dependent on
data access implementation details (and often on the existence of a database). Testing business logic
in such an architecture is often difficult, requiring a test database. The dependency inversion principle
can be used to address this issue, as you’ll see in the next section.

Figure 5-3 shows an example solution, breaking the application into three projects by responsibility
(or layer).

18 CHAPTER 4 | Common web application architectures

Figure 5-3. A simple monolithic application with three projects.

Although this application uses several projects for organizational purposes, it’s still deployed as a
single unit and its clients will interact with it as a single web app. This allows for very simple
deployment process. Figure 5-4 shows how such an app might be hosted using Azure.

Figure 5-4. Simple deployment of Azure Web App

As application needs grow, more complex and robust deployment solutions may be required. Figure
5-5 shows an example of a more complex deployment plan that supports additional capabilities.

19 CHAPTER 4 | Common web application architectures

Figure 5-5. Deploying a web app to an Azure App Service

Internally, this project’s organization into multiple projects based on responsibility improves the
maintainability of the application.

This unit can be scaled up or out to take advantage of cloud-based on-demand scalability. Scaling up
means adding additional CPU, memory, disk space, or other resources to the server(s) hosting your
app. Scaling out means adding additional instances of such servers, whether these are physical
servers, virtual machines, or containers. When your app is hosted across multiple instances, a load
balancer is used to assign requests to individual app instances.

The simplest approach to scaling a web application in Azure is to configure scaling manually in the
application’s App Service Plan. Figure 5-6 shows the appropriate Azure dashboard screen to configure
how many instances are serving an app.

20 CHAPTER 4 | Common web application architectures

Figure 5-6. App Service Plan scaling in Azure.

Clean architecture
Applications that follow the Dependency Inversion Principle as well as the Domain-Driven Design
(DDD) principles tend to arrive at a similar architecture. This architecture has gone by many names
over the years. One of the first names was Hexagonal Architecture, followed by Ports-and-Adapters.
More recently, it’s been cited as the Onion Architecture or Clean Architecture. The latter name, Clean
Architecture, is used as the name for this architecture in this e-book.

The eShopOnWeb reference application uses the Clean Architecture approach in organizing its code
into projects. You can find a solution template you can use as a starting point for your own ASP.NET
Core on the ardalis/cleanarchitecture GitHub repository.

Clean architecture puts the business logic and application model at the center of the application.
Instead of having business logic depend on data access or other infrastructure concerns, this
dependency is inverted: infrastructure and implementation details depend on the Application Core.
This functionality is achieved by defining abstractions, or interfaces, in the Application Core, which are
then implemented by types defined in the Infrastructure layer. A common way of visualizing this
architecture is to use a series of concentric circles, similar to an onion. Figure 5-7 shows an example of
this style of architectural representation.

21 CHAPTER 4 | Common web application architectures

Discovering Diverse Content Through
Random Scribd Documents
The Project Gutenberg eBook of Blackwood's
Edinburgh Magazine, Vol. 79, No. 484,
February, 1856
 This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

Title: Blackwood's Edinburgh Magazine, Vol. 79, No. 484,

February, 1856

Author: Various

Release date: March 26, 2024 [eBook #73265]

Language: English

Credits: Richard Tonsing, Jonathan Ingram, Brendan OConnor,

and the Online Distributed Proofreading Team at
https://www.pgdp.net (This file was produced from
images generously made available by The Internet
Archive)

*** START OF THE PROJECT GUTENBERG EBOOK

BLACKWOOD'S EDINBURGH MAGAZINE, VOL. 79, NO. 484,
FEBRUARY, 1856 ***
Transcriber’s Note:
New original cover art included with this eBook is
granted to the public domain.
 BLACKWOOD’S

EDINBURGH MAGAZINE.

No. CCCCLXXXIV. FEBRUARY 1856.

Vol. LXXIX.
 CONTENTS.

Modern Light Literature—Poetry, 125

A Military Adventure in the Pyrenees—concluded, 138
The Wondrous Age, 154
Public Lectures—Mr Warren on Labour, 170
Touching Oxford, 179
The Ancient Coins of Greece, 193
Tickler among the Thieves! 200
The Drama, 209
Lessons from the War, 232
Religion in Common Life, 243

EDINBURGH:
WILLIAM BLACKWOOD & SONS, 45
GEORGE STREET,
AND 37 PATERNOSTER ROW, LONDON;
To whom all communications (post paid) must be addressed.

SOLD BY ALL THE BOOKSELLERS IN THE UNITED KINGDOM.

PRINTED BY WILLIAM BLACKWOOD AND SONS, EDINBURGH.

 BLACKWOOD’S

EDINBURGH MAGAZINE.

No. CCCCLXXXIV. FEBRUARY, 1856.

Vol. LXXIX.

MODERN LIGHT LITERATURE—POETRY.

“Poets,” said the ancient wisdom, “are not made, but born.” We
have made miraculous progress in all the arts of manufacture since
the time of this saying, but we have not been able to controvert the
judgment of our forefathers. Education, refinement, taste, and talent,
are great things in their way, and men do wonders with them; but we
have not fallen yet upon a successful method of bringing down the
divine spark into the marble, let us work it ever so curiously. The
celestial gift in these new times, as in the old, comes down with
divine impartiality, yet seldom into the tenement most specially built
and garnished for its reception. We can make critics, connoisseurs,
“an enlightened audience,” but, let us labour at it as we will, we
cannot make a poet.
 And indeed, to tell the truth, it is but small help we can give, with
all our arts and ingenuities, even to the perfecting of the poet born.
Science discusses the subject gravely—at one time troubled with
apprehensions lest her severe shadow should kill the singer outright,
as Reason killed Love—at another, elate with the happier thought of
increasing all his conquests, and sending forth as her own esquire,
bearing her ponderous lance and helmet, the glorious boy in his
perennial youth. It is a vain speculation. The poet glances past this
important figure with a calm eye and a far-shining smile. His
vocation is beyond and beyond the range of all the sciences. The
heart and soul that were in the first home, ere ever even spade and
distaff were invented, when two forlorn hopeful creatures, wistfully
looking back to the sunset of Eden, wistfully looking forward to the
solemn nightfall of the drear world without, with all its starry
promises of another morning and a higher heaven, were all the
human race—are world and scope enough for the humanest and
most divine of arts. That God has made of one blood all the nations
and all the generations of this many-peopled earth, is the argument
on which he speaks; that heart answers unto heart all the world over,
is the secret of his power. The petulant passion of a child, the
heroisms and exultations and agonies of that fantastical sweet youth,
over whose unconscious mockery of our real conflict we graver
people smile and weep, are of more import to the poet than all the
secrets of the earth, and all the wonders of the sky; and he turns—it
is his vocation—from the discovery of a planet, forgetting all about it,
to make the whole world ring with joy over a cottage cradle, or weigh
down the very wings of the winds with wailing over some
uncommemorated grave.
Yes, it is a humiliating confession—but in reality we are quite as
like to injure as to elevate our poet by all our educations. Perhaps the
heavenly glamour in his eyne had best be left entirely unobscured by
any laws save those of nature; but at all events it seems tolerably
sure, that the more we labour at his training, the less satisfactory is
the result of it. A school of poets is the most hopeless affair in
existence; and whether it dwindle into those smallest of small
rhymsters, leaden echoes of the silver chimes of Pope, in whom the
eighteenth century delighted, or to the present makers of dislocated
verses, whose glory it is to break stones upon the road where the
Laureate’s gilded coach flashes by, we wait with equal weariness and
equal impatience for the Coming Man, who knows neither school nor
education—whose business it is to rout the superannuated spinsters,
and make the world ring once more with the involuntary outburst of
song and youth.
But we who are but the unhappy victims of the mania, why do we
blame ourselves? Alas! it is not we, but our poets, foolish fraternity,
who have set about this fatal task of making a school and perfecting
themselves in their art. How do you suppose they are to do it, kindest
reader? In other arts and professions the self-love of the student in
most instances suffers a woeful downfall at his very outset. Tutors
and books, dire conspirators against his innocence, startle the
hapless neophyte out of all his young complacency; professors set
him down calmly as a know-nothing; chums, with storms of laughter,
drive him out of his last stronghold. He has to shut himself out from
his college doors; seal himself up, poor boy, in his home letters, and
so sit down and study other people’s wisdom, till he comes by that far
away and roundabout process to some true estimate of his own.
But the poet, say the poets, needs other training. For him it is
safest that we shut him up with himself. Himself, a separated
creature, garlanded and crowned for the sacrifice, is, in one noble
concentration, all the ethics, the humanity, and the religion with
which he has to do; significances, occult and mysterious, are in every
breath of wind that whispers about his dedicated head; his smallest
actions are note-worthy, his sport is a mystery, his very bread and
cheese symbolical. He is a poet—everywhere, and in all places, it is
the destiny of this unfortunate to reverence himself, to contemplate
himself, to expound and study the growth of a poet’s mind, the
impulses of a poet’s affections; he is not to be permitted to be
unconscious of the sweet stirrings within him of the unspoken song;
he is not to be allowed to believe with that sweetest simplicity of
genius that every other youthful eye beholds “the light that never was
on sea or land,” as well as his own. Unhappy genius! ill-fated poet!
for him alone of all men must the heavens and the earth be blurred
over with a miserable I,—and so he wanders, a woeful Narcissus,
seeing his own image only, and nothing better, in all the lakes and
fountains; and, bound by all the canons of his art, falls at last
desperately either in love or in hate with the persistent double,
which, go where he will, still looks him in the face.
 But we bethink us of the greater poets, sons of the elder time.
There was David, prince of lyric-singers; there was Shakespeare,
greatest maker among men. The lyricist was a king, a statesman, a
warrior, and a prophet; the leisure of his very youth was the leisure
of occupation, when the flocks were feeding safe in the green
pastures, and by the quiet waters; and even then the dreaming poet-
eye had need to be wary, and sometimes flashed into sudden
lightning at sight of the lion which the stripling slew. He sung out of
the tumult and fulness of his heart—out of the labours, wars, and
tempests of his most human and most troubled life: his business in
this world was to live, and not to make poems. Yet what songs he
made! They are Holy Writ, inspired and sacred; yet they are human
songs, the lyrics of a struggling and kingly existence—the overflow of
the grand primal human emotions to which every living heart
resounds. His “heart moved him,” his “soul was stirred within him”—
true poet-heart—true soul of inspiration! and not what other men
might endure, glassed in the mirror of his own profound poetic
spirit, a study of mankind; but of what himself was bearing there and
at that moment, the royal singer made his outcry, suddenly, and “in
his haste,” to God. What cries of distress and agony are these! what
bursts of hope amid the heartbreak! what shouts and triumphs of
great joy! For David did not live to sing, but sang because he strove
and fought, rejoiced and suffered, in the very heart and heat of life.
Let us say a word of King David ere we go further. Never crowned
head had so many critics as this man has had in these two thousand
years; and many a scorner takes occasion by his failings, and
religious lips have often faltered to call him “the man after God’s own
heart;” yet if we would but think of it, how touching is this name! Not
the lofty and philosophic Paul, though his tranced eyes beheld the
very heaven of heavens; not John, although the human love of the
Lord yearned towards that vehement angel-enthusiast, whose very
passion was for God’s honour; but on this sinning, struggling,
repenting David, who fights and falls, and rises only to fall and fight
again—who only never will be content to lie still in his overthrow,
and acknowledge himself vanquished—who bears about with him
every day the traces of some downfall, yet every day is up again,
struggling on as he can, now discouraged, now desperate, now
exultant; who has a sore fighting life of it all his days, with enemies
within and without, his hands full of wars, his soul of ardours, his life
of temptations. Upon this man fell the election of Heaven. And small
must his knowledge be, of himself or of his race, who is not moved to
the very soul to think upon God’s choice of this David, as the man
after His own heart. Heaven send us all as little content with our sins
as had the King of Israel! Amen.
And then there is Shakespeare: never man among men, before or
after him, has made so many memorable people; yet amid all the
crowding faces on his canvass, we cannot point to one as “the
portrait of the painter.” He had leisure to make lives and histories for
all these men and women, but not to leave a single personal token to
us of himself. The chances seem to be, that this multitudinous man,
having so many other things to think of, thought marvellously little
of William Shakespeare; and that all that grave, noble face would
have brightened into mirthfullest laughter had he ever heard, in his
own manful days, of the Swan of Avon. His very magnitude, so to
speak, lessens him in our eyes; we are all inclined to be apologetic
when we find him going home in comfort and good estate, and
ending his days neither tragically nor romantically, but in ease and
honour. He is the greatest of poets, but he is not what you call a
poetical personage. He writes his plays for the Globe, but, once
begun upon them, thinks only of his Hamlet or his Lear, and not a
whit of his audience; nor, in the flush and fulness of his genius, does
a single shadow of himself cross the brilliant stage, where, truth to
speak, there is no need of him. The common conception of a poet, the
lofty, narrow, dreamy soul, made higher and more abstract still by
the glittering crown of light upon his crested forehead, is entirely
extinguished in the broad flood of sunshine wherein stands this
Shakespeare, a common man, sublimed and radiant in a very deluge
and overflow of genial power. Whether it be true or not that these
same marvellous gifts of his would have made as great a statesman
or as great a philosopher as they made a poet, it does not lie in our
way to discover; but to know that the prince of English poets did his
work, which no man has equalled, with as much simplicity and as
little egotism as any labouring peasant of his time—to see him setting
out upon it day by day, rejoicing like a strong man to run a race, but
never once revealing to us those laborious tokens of difficulties
overcome, which of themselves, as Mr Ruskin says, are among the
admirable excellences of Art—to perceive his ease and speed of
progress, and how his occupation constantly is with his story and
never with himself,—what a lesson it is! But alas, and alas! we are
none of us Shakespeares. Far above his motives, we would scorn to
spend our genius on a Globe Theatre, or on any other vulgar manner
of earning daily bread. The poet is a greater thing than his poem; let
us take it solely as an evidence of his progress; and in the mean time,
however he may tantalise the world with his gamut and his exercises,
let all the world look on with patience, with awe, and with
admiration. True, he is not making an Othello or a Hamlet; but never
mind, he is making Himself.
Yet the thought will glide in upon us woefully unawares,—What
the better are we? We are ever so many millions of people, and only a
hundred or two of us at the utmost can be made happy in the
personal acquaintanceship of Mr Tennyson or (we humbly crave the
Laureate’s pardon for the conjunction) Mr Dobell. In this view of the
question, it is not near so important to us that these gentlemen
should perfect the poet, as that they should make the poem. We ask
the Laureate for a battle-song, and he gives us a skilful fantasia upon
the harp; we hush our breath and open our ears, and, listening
devoutly to the “Eureka!” of here and there a sanguine critic, who has
found a poet, wait, longing for the lay that is to follow. Woe is upon
us!—all that we can hear in the universal twitter is, that every man is
trying his notes. We are patient, but we are not a stoic; and in the
wrath of our disappointment are we not tempted a hundred times to
plunge these melodious pipes into the abyss of our waste-paper
basket, and call aloud for Punch, and the Times?
Yes, that great poetic rebel, Wordsworth, has heavier sins upon his
head than Betty Foy and Alice Fell; it is to him we owe it, that the
poet in these days is to be regarded as a delicate monster, a creature
who lives not life but poetry, a being withdrawn out of the common
existence, and seeing its events only in the magic mirror of his own
consciousness, as the Lady of Shallott saw the boats upon the river,
and the city towers burning in the sun. The Poet of the Lakes had no
imaginary crimes to tell the world of, nor does it seem that he
regarded insanity as one of the highest and most poetic states of
man; but we venture to believe there never would have been a
Balder, and Maud should have had no crazy lover, had there been no
Recluse, solemnly living a long life for Self and Poetry in the retired
and sacred seclusion of Rydal Mount.
 It is in this way that the manner which is natural and a necessity to
some one great spirit, becomes an intolerable bondage and
oppression to a crowd of smaller ones. The solemn egotism, self-
reserved and abstract, which belonged to Wordsworth, is more easily
copied than the broad, bright, manful nature of our greatest English
poet, who was too mighty to be peculiar; and the delusion has still a
deeper root. It is in our nature, as it seems, to scorn what is familiar
and common to all the world; priesthoods, find them where you will,
are bound to profess a more ethereal organisation, and seek a
separated atmosphere. Wordsworth is a very good leader; but for a
thorough out-and-out practical man, admitting no compromise with
his theory, commend us to Anthony the Eremite, the first of all
monkish deserters from this poor sinking vessel, the world. The poet
is the priest of Nature; out with him from this Noah’s ark of clean
and unclean,—this field of wheat and tares, growing together till the
harvest,—this ignoble region of common life. Let the interpreter
betake him to his monastery, his cloister, his anchorite’s cell—and
when he is there? Yes, when he is there—he will sing to us poor
thralls whom he has left behind, but not of our ignoble passions and
rejoicings, or the sorrows that rend our hearts. Very different from
our heavy-handed troubles, rough troopers in God’s army of
afflictions, are the spectre shapes of this poetic world. True, their
happiness is rapture, their misery of the wildest, their remorse the
most refined; but the daylight shines through and through these
ghostly people, and leaves nothing of them but bits of cloud. Alas, the
preaching is vain and without profit! What can the poet do—when he
is tired of his Mystic, sick of his Balder, weary of Assyrian bulls and
lords with rabbit-mouths? Indeed, there seems little better left for
him than what his predecessors did before. The monk spent his soul
upon some bright-leaved missal, and left the record of his life in the
illumination of an initial letter, or the border of foliage on a vellum
page; the poet throws away his in some elaborate chime of words,
some new inverted measure, or trick of jingling syllables. Which is
the quaintest? for it is easy to say which is the saddest waste of the
good gifts of God.
Also it is but an indifferent sign of us, being, as we undoubtedly
are, so far as poetry is concerned, a secondary age, that there can be
no dispute about the first poet of our day. There is no elder
brotherhood to compete for the laurel; no trio like Wordsworth,
Coleridge, and Southey; no guerilla like Byron to seize upon the
contested honour, nor Irish minstrel to strike a sugared note of
emulation. Should a chance arrow at this moment strike down our
poetic champion, so far from comforting ourselves, like King Henry,
that we have “five hundred as good as he,” we could not find for our
consolation one substitute for Tennyson. Echoes of him we could
indeed find by the score; but no one his entire equal in all the field.
Let no one say we do not appreciate poetry; in these mechanical days
there are still a goodly number of singers who could echo that
unfortunate admission which cost Haverillo his life, and was the last
stroke of exasperation to the redoubtable Firmilian, “I have a third
edition in the press.” But in spite of Smith and Dobell, the Brownings
and the Mystics, our Laureate holds his place; holding his laurel with
justice and right less disputable than most of his predecessors. Yet
our admiration of Tennyson is perplexed and unsatisfactory. He is
the first in his generation, but out of his generation he does not bear
comparison with any person of note and fame equal to his own. He is
small in the presence of Wordsworth, a very inferior magician indeed
by the side of Coleridge; his very music—pardon us, all poets and all
critics!—does not flow. It may be melodious, but it is not winged; one
stanza will not float into another. It is a rosary of golden beads, some
of them gemmed and radiant, fit to be set in a king’s crown; but you
must tell them one by one, and take leisure for your comment while
they drop from your fingers. They are beautiful, but they leave you
perfectly cool and self-possessed in the midst of your admiration. To
linger over them is a necessity; it becomes them to be read with
criticism; you go over the costly beadroll and choose your single
favourites here and there, as you might do in a gallery of sculpture.
And thus the poet chooses to make you master of his song,—it does
not seize upon you.
This is a kind and manner of influence which poets have not often
aimed at. Hitherto it has been the object of this fraternity to arrest
and overpower their audience as the Ancient Mariner fascinated the
wedding guest; and we all know how helplessly, and with what
complete submission, we have followed in the train of these
enchanters, wheresoever it pleased them to turn their wayward
footsteps. But Mr Tennyson aims at a more refined and subtle
influence than this downright enslaving. A poet who writes, or seems
to write, because he cannot help it,—and a poet who writes, or seems
to write, of set purpose and malice prepense, are two very different
persons. A man of the first class could not have written In
Memoriam. Had he been mourning, he must have mourned a closer
grief, and broken his heart over it, ere he had wept the half of those
melodious tears; but for the poet quietly selecting a subject for his
poem, the wisest philosopher could not have suggested a better
choice. A great deal has been said and written on this subject, and we
are fully aware that grief does not make books, or even poems, except
in very rare and brief instances, and that the voice of a great sorrow
is a sharp and bitter outcry, and not a long and eloquent monologue.
But Mr Tennyson does not present himself to us under the strong
and violent compulsion of a great sorrow. It is not grief at his heart
which makes him speak, using his gifts to give ease and utterance to
its burden of weeping; but it is himself who uses his grief, fully
perceiving its capabilities, and the entrance it will give him into the
sacred and universal sympathy of his fellows. For, like all great works
of art, this poem appeals to one of the primitive and universal
emotions of human nature. The dead—the early dead, the beloved,
the gifted, the young: we may discuss the appropriateness of the
tribute, but we cannot refuse to be moved by its occasion. No man
can look on these pages without finding here and there a verse which
strikes home; for few of us are happy enough to live so much as
twenty years in this weary world of ours without some In Memoriam
of our own.
Yet we cannot complain of Mr Tennyson that he makes
merchandise of any of the nearest and closest bereavements, the
afflictions which shake the very balance of the world to those who
suffer them. His sorrow is as much of the mind as of the heart; he
weeps a companion beloved, yet almost more honoured and
esteemed than beloved—a friend, not even a brother, still less a child
or a wife;—enough of the primitive passion to claim sympathy from
all of us, but not so much that our sympathy loses itself in a woe
beyond consolation. Pure friendship is seldom so impassioned; but
had it been a commoner tie—a relationship more usual—these
gradual revelations of grief in all its successive phases must have
been too much at once for the poet and his audience. This nice
discrimination secures for us that we are able to read and follow him
into all those solemn regions of thought and fancy which open at the
touch of death; he does not fall down upon the grave, the threshold,
as we are but too like to do, and we wander after him wistfully,
beguiled with the echo of this thoughtful weeping, which must have
overpowered us had it been as close or as personal as our own. We
feel that over our own minds these same thoughts have flashed now
and then—a momentary gleam—while we were wading in the bitter
waters, and woefully making up our minds, a hundred times in an
hour, to the will of God; but who could follow them out? The poet,
more composed, does what we could not do; he makes those flashes
of hope or of agony into pictures visible and true. Those glimpses of
the face of the dead, of the moonlight marking out upon the marble
the letters of his name, those visions of his progress now from height
to height in the pure heavens, all the inconsistent lights and shadows
—mingled thoughts of the silence in the grave, and of the sound and
sunshine of heaven—not one of them is passed over. People say it is
not one poem, but a succession of poems. It must have been so, or it
would not have been true. One after another they come gleaming
through the long reverie of grief—one after another, noting well their
inconsistencies, their leaps from day to night, from earth to heaven,
the poet has set them down. He knows that we think of the lost, in
the same instant, as slumbering under the sod and as awaking above
the sky; he knows that we realise them here and there, as living and
yet as dead; he knows that our
“fancy fuses old and new,
And flashes into false and true,
And mingles all without a plan.”

It is the excellence of In Memoriam that it is a succession of poems

—that the thread of connection runs loosely—now and then drops,
and as unexpectedly comes to light again—that the sequence of these
fancies knows no logic, and that they come in the strain as they come
to the heart.
At the same time it is equally true that all this is done of set
purpose and intention—that the act with which, glimpse by glimpse,
the whole tearful chronicle is made visible, is a calm deliberate act,
and not a voice out of the present passion of a heartbreaking grief.
The poet has chosen the theme—it is not the theme which urges with
an overpowering impulse the utterance of the poet.
 And so it is with all Mr Tennyson’s verses, for—no disparagement
to his poetic power—verses we must call them. It is true he is now
and then moved by some sudden exclamation, and shouts it out with
an unexpected force which startles his readers, for the moment, into
a more eager sympathy—but for the most part this poet holds his
verse in perfect subordination, and is never overcome or led away by
it. His poetry is made, it is not born. When he can round a sentence
into a stanza, the effect, of its kind, is perfect; but the very form of his
favourite measure, the rhythm of In Memoriam, is against any real
outburst of involuntary song; for the verse which falls so sweetly
when it contains all that belongs to it within its perfect crystal round,
like a dewdrop, makes only a most blurred and unshapely strain
when it has to eke out its sense with another and another stanza.
When the necessities of his subject force him to this, the poet labours
like a man threading together a succession of fish-ponds in hopes of
making a river. Of themselves these silvery globes are perfect, but
there is no current in them, and, work as you will, they can never
flow and glow into a living stream. Yes, our Laureate unhappily is
always far too much “master of his subject;” would that his subject
now and then could but master him!
If it should happen, by any chance, that Mr Tennyson shared in
Wordsworth’s solemn conceit, and designed to make a Gothic
cathedral out of his works and life, we marvel much what place in it
could be given to The Princess, that prettiest of poetic extravagances.
Not a Lady-chapel, though it is of a college of ladies that the story
treats—not a delicate shrine, all wrought in lilies and graces of
foliage, like the shrine of some sweet maiden-saint. No; the Marys,
the Catherines, and the Margarets, symbolised an entirely different
fashion of womankind; yet have we the greatest kindness for Ida in
her girlish heroics, sincerest of all fictions—in her grand words, and
her pride, her inconstant subjects, and her own self-betraying heart.
For our own part, we are so entirely weary of symbols, that we do not
pause to inquire whether The Princess means anything more than it
professes to mean. To us it is only a pleasant picture of the
phantasies of youth.
The sweet and daring folly of girlish heroics and extravagance has
not done half so much service to the poet and story-teller as has the
corresponding stage in the development of man. Yet there is more
innocence in it, and perhaps in its full bloom its pretensions are even
more sublime. The delicate temerity which dares everything, yet at
its very climax starts away in a little sudden access of fear—the
glorious young stoic, who could endure a martyrdom, yet has very
hard ado to keep from crying when you lose her favourite book or
break her favourite flower—the wild enthusiast dreamer, scorning all
authorities, who yet could not sleep o’ nights if she had transgressed
by ever so little the sweet obedience of home,—there is a charm
about this folly almost more delightful than the magic of the bolder
youth, with all its bright vagaries; and it is this which makes our
tenderness for the Princess Ida and all her “girl graduates in their
golden hair.”
Strange enough, however, this phase of youthfulness does not
seem to have struck any woman-poet. We have heroines pensive and
heroines sublime, heroines serious and heroines merry, but very few
specimens of that high fantastical which embraces all these, and into
which most men, and doubtless most women, on their way to soberer
life, have the luck to fall. Mrs Browning is too sad, too serious, too
conscious of the special pangs and calamities which press heaviest on
her sisterhood, to take note of any happier peculiarity. Nor is this
special eye to feminine troubles confined to Mrs Browning: a
weeping and a melancholy band are the poetesses of all generations.
“Woman is the lesser man,” says the Laureate; but only woman is the
sadder man—the victim set apart on a platform of injury—the
wronged and slighted being whose lot it is to waste her sweetness on
hearts unkind and ungrateful, say all the ladies. “Her lot is on you.”
The mature woman has no better thought, when she looks over the
bright girl-heads, bent in their morning prayer; and wherever we
have a female singer, there stands woman, deject and pensive,
betrayed, forsaken, unbeloved, weeping immeasurable tears. Is a
woman, then, the only creature in God’s universe whom He leaves
without compensation? Out upon the thought! but there ought to be
some Ida bold enough to proclaim the woman’s special happinesses
—the exuberant girl-delights—the maiden meditation, fancy free—
the glory of motherhood—the blessings as entirely her own as are the
griefs. Bertha in the Lane is a most moving story, sweetly told; but ye
are not always weeping, O gentlest sisterhood! and where are your
songs of joy?
 If Mr Tennyson intends the hysterical folly of Maud for a
companion picture to this one, he is indeed elevating the woman to a
higher pedestal than even Ida dreamed of; for the youth is a
miserable conception in comparison with this sunbright girl. In the
beginning of the last reign of poets—when men, disturbed by the
great rustle of the coming wings, endeavoured to find out wherein
the magic consisted, to which they could not choose but yield—we
remember to have seen many clever speculations on the nature of
poetry “One said it was the moon—another said nay”; and it was very
hard to understand the unreasonable potency of this enchantment—
which, indeed, clever people, unwilling to yield to an influence which
they cannot measure, are perpetually accounting for by rules and
principles of art. “It has always been our opinion,” says Lord Jeffrey,
“that the very essence of poetry, apart from the pathos, the wit, or the
brilliant description which may be embodied in it, but may exist
equally in prose, consists in the fine perception and vivid expression
of that subtle and mysterious analogy which exists between the
physical and the moral world—which makes outward things and
qualities the natural types and emblems of inward gifts and
emotions, and leads us to ascribe life and sentiment to everything
that interests us in the aspects of external nature.” Lord Jeffrey is a
good authority, though sometimes this troublesome poetry put even
the accomplished critic out of his reckoning; but we are sadly afraid
that this deliverance of his, or at least the idea it contains, has had
some share in the present insanity of all our poets in regard to
Nature. Mr Tennyson may have a private reason of his own for
making such a miserable grumbler as his last hero. Mr Dobell may
hold himself justified, in the heights of self-complacence, and for the
benefit of art, for his atrocious Balder, a criminal, by all poetic laws,
for prosiness interminable, worse than murder; but we would crave
to know what right these gentlemen may have to seize upon our
genial nature, and craze her healthful looks and voices to their
hysterical and ghastly fancy? We are content, if he uses his own
materials, that the Laureate should dabble his hollow with blood to
his heart’s content; but we will not consent, for a hundred laureates,
to make the free heather of our hills, the kindly blossom sacred to
home and to liberty, an image of disgust and horror. After all, this is
a very poor trick and a contemptible—at its best much like that which
Mr Ruskin denounces as the most ignoble thing in painting, the