.NET Core新篇章：探索微服务、ASP.NET Core与EF Core

需积分: 9 89 浏览量更新于2024-07-18 收藏 12.07MB PDF 举报

"Free .NET Core eBook 包含 ASP.NET Core 和 EF Core" 这篇资源介绍了一本免费的 .NET Core 电子书，该书详细探讨了使用微服务、ASP.NET Core 和 Entity Framework Core 进行开发的主题。这本书由 Dustin Metzgar 选择并推荐，由 Manning Publications 出版。它特别关注了 .NET Core 如何在现代开发环境中提供跨平台支持、高性能以及开源社区的繁荣。首先，.NET Core 是微软推出的一个全新、开放源代码的框架，旨在解决传统 .NET Framework 只能在 Windows 上运行的问题。现在，.NET Core 已经支持 Linux，这大大扩展了其适用范围，并且它的源代码对公众开放，促进了强大的开源社区发展。这个框架的设计理念是轻量级和模块化，从而更专注于提供高性能的应用程序。对于已经熟悉 .NET Framework 的开发者来说，.NET Core 带来了许多新特性，如容器支持，这是一个现代化应用程序部署的重要工具。ASP.NET Core 是一个针对 Web 应用程序开发的框架，它比其前身 ASP.NET 更加轻量级和高效，支持跨平台，允许开发者在多种操作系统上构建高性能的 Web 应用。同时，ASP.NET Core 与 .NET Core 集成紧密，可以充分利用 .NET Core 的优势。另外，Entity Framework Core (EF Core) 是微软的下一代对象关系映射 (ORM) 工具，它是 Entity Framework 的轻量级版本，适用于 .NET Core。EF Core 提供了数据访问层的抽象，使得开发者可以更方便地与数据库交互，而无需编写大量的 SQL 代码。它支持多种数据库系统，包括 SQL Server、SQLite、PostgreSQL 等，具有高度可配置性和可扩展性。这本书将深入讲解如何利用这些技术来构建微服务架构。微服务是一种软件开发方法，通过将大型应用程序拆分为一组小型、独立的服务来实现，每个服务都可以独立开发、部署和扩展。使用 ASP.NET Core 和 EF Core，开发者能够构建可扩展、高可用性的微服务系统，这些系统通常更加灵活，适应性强，易于维护和升级。总而言之，这本书面向的是那些想要探索 .NET Core、ASP.NET Core 和 EF Core 在微服务架构中的应用的开发者。无论是对 .NET 新手还是经验丰富的开发者，都能从中获得宝贵的见解和实践指导，帮助他们跟上当前的技术趋势，提升开发效率和应用性能。通过阅读这本书，读者将有机会学习到如何利用这些先进的技术来构建高性能、跨平台的现代应用程序。

11Common legacy code traits and refactorings

Imagine that you maintain World of RuneQuest, an online fantasy RPG. You’re

planning to start development on a new version of the game, but recently you’ve

noticed that the code has become bloated and disorganized, and development veloc-

ity has dropped as a result. You want to give the

codebase a thorough spring clean

before you start developing the new version. Let’s look at some areas you could tackle.

4.2.1 Stale code

Stale code is any code that remains in the codebase even though it’s no longer

needed. Deleting this unneeded code is one of the easiest, safest, and most satisfying

refactoring tasks you can hope for. Because it’s so easy, it’s often a good way to warm

up before embarking on more serious refactoring.

Removal of stale code has a number of benefits:

 It makes the code easier to understand, because there’s now less code to read.

 It reduces the chance of somebody wasting time on fixing or refactoring code

that isn’t even used.

 As a satisfying bonus, every time you delete some code, the project’s test cover-

age increases.

Stale code can be divided into a few categories.

COMMENTED-OUT CODE

This is the lowest of all low-hanging fruit. If you see a block of code that has been com-

mented out, don’t think twice, just delete it! There’

s absolutely no reason to leave

commented-out code lying around. It’s often left deliberately as a record of how the

code was changed, but that’s exactly what the version control system is for. It’s point-

less noise, making the surrounding

code more difficult to read.

DEAD CODE

Dead code is any code in your software that will definitely never be executed. It might

be a variable that’s never used, a branch of an

statement that’s never taken, or even

a whole package of code that’s never referenced.

In the following simple exam

ple of dead code, the

armorStrength

variable can

never have a value greater than 7, so it’s always less than 10 and the

else

block will

never run. It’s dead code and thus can and should be removed.

int armorStrength = 5;

if (player.hasArmorBoost()) {

armorStrength += 2;

}

...

if (armorStrength < 10) {

Armor strength is always 7 or less,

so this branch will always run.

defenceRatio += 0.1;

} else {

defenceRatio += 0.2;

This branch is dead code.

}

Licensed to UNKNOWN UNKNOWN <cdjboy@163.com>

12 CHAPTER 4 Refactoring

There are many tools that can help you find and remove dead code from your code-

base. Most

IDEs will point out fields, methods, and classes that aren’t referenced, and

tools such as FindBugs (discussed in chapter 2) also include relevant rules.

ZOMBIE CODE

Some code that’s actually dead may look very much alive. I call this zombie code. Its

liveliness (or lack of) is impossible to discover just from reading the surrounding

source. Examples include

 Code that branches based on data received from an external source such as a

database, in which some of the branches are never triggered

 Pages of a website or screens of a desktop application that are no longer linked

from anywhere

As an example of the first point, let’s alter th

e previous code sample so that the value

armorStrength

is read from a DB. Just by reading the code, you have no idea what

value

armorStrength

might have, so the code looks alive and reasonable.

int armorStrength = DB.getArmorStrength(play.getId());

...

if (armorStrength < 10) {

defenceRatio += 0.1;

} else {

defenceRatio += 0.2;

Is this branch dead or alive?

}

But when you look at the actual data in the DB, you might find that all 5 million play-

ers have an armor strength of less than 10, so in fact the

else

will never run.

In this case, you should check all the places that are setting this value in the

DB (to

make sure that a strength of 10 or more is impossible), and then add a

DB constraint

to act as documentation for your understanding of the model, before finally deleting

the unneeded

else

block.

In the case of pages or screens that aren’

t linked from anywhere, it’s often difficult

and time-consuming to confirm that a given page of a web application is dead. Even if

there are no links to it, users might still be accessing it directly, perhaps via browser

bookmarks, so you may have to trawl through web server access logs to check that the

page is safe to delete.

I was affected by a real-world example of zombie

code when I joined a team that

maintained a large legacy web application. Before I joined the team, they’d been

A/B

testing a major update to the site’s top page. There were two separate versions of the

page, and users were directed to one or the other based on a per-user flag in the

DB.

Little did I know, the

A/B test had already finished (the flags in the DB had all been set

to the same value) but nobody had deleted the losing version of the page. So every

time I had to make a change to the top page, I faithfully replicated my changes across

both versions, wasting a lot of time in the process.

Licensed to UNKNOWN UNKNOWN <cdjboy@163.com>

13Common legacy code traits and refactorings

A/B TESTING A/B testing is a commonly used process to investigate the effect

that a change to a website will have on users’ behavior. The basic idea is to

introduce the change to only a limited segment of the site’s users at first.

Users are separated into two buckets, A and B, and one group is served the

normal site, while the other is served a version of the site that includes the

change. You then measure key metrics (page views, attention time, scroll

depth, and so on) for each user segment and compare the results.

EXPIRED CODE

It’s common for business logic to apply only within a certain timespan, especially in

web applications. For example, you might run a particular ad campaign or A/B test

for a few weeks. In World of RuneQuest, perhaps you run half-price sales on in-game

purchases occasionally. This often requires corresponding date-specific logic in the

code, so it’s common to see code that looks like this:

if (new DateTime("2014-10-01").isBeforeNow() &&

new DateTime("2014-11-01").isAfterNow()) {

// do stuff ...

}

While there’s nothing wrong with temporary code like this, developers often forget to

go back and delete it after it has served its purpose, leading to a codebase littered with

expired code.

There are a couple of ways of avoiding this problem. One is to file a ticket in your

issue tracker to remind yourself to delete the code. In this case, make sure that the

ticket has a deadline and is assigned to a specific person; otherwise it’s easily ignored.

A smarter solution is to automate the check for expired code.

1 When writing code that has a limited lifespan, add a code comment in a specific

format to mark it as expiring code.

2 Write a script that can search through the codebase, parse these comments, and

flag any expired ones.

3 Set up your CI server to run this script regularly and fail the build if it finds any

expired code. This should be much harder to ignore than a ticket in the issue

tracker.

The following code shows an example of one of these comments.

// EXPIRES: 2014-11-01

if (new DateTime("2014-10-01").isBeforeNow() &&

new DateTime("2014-11-01").isAfterNow()) {

// do stuff ...

}

AUTOMATING EXPIRY CHECKS USING MACROS In languages that support mac-

ros (running code at compile time), it’s possible to make the project fail to

compile if there’s any expired code lying around. I know of a couple of Scala

libraries that can do this for you: Fixme (https://github.com/tysonjh/fixme)

and DoBy (https://github.com/leanovate/doby).

Licensed to UNKNOWN UNKNOWN <cdjboy@163.com>

14 CHAPTER 4 Refactoring

4.2.2 Toxic tests

When you’re handed a legacy project to maintain, you might count yourself lucky if it

includes some automated tests. They can often act as a good substitute for documen

tation, and the presence of tests gives a hint that the code quality might be reasonable.

But be careful: there are some kinds of tests that are worse than no tests at all. I call

these toxic tests. Let’s have a look at some of them.

TESTS THAT DON’T TEST ANYTHING

The basic template for a good software test, no matter whether it’s manual or auto-

mated, unit, functional, system, or whatever, can be summed up in just three words:

given-when-then.

 Given some preliminary conditions and assumptions,

 when I do this

 then this should be the result.

Surprisingly often I encounter tests in legacy projects that don’t fit this simple pattern.

I see a lot of tests that are missing the “then” part, meaning that they don’t include any

assertions to check the result of the test against what was expected.

Imagine that World of RuneQuest uses an event bus to manage in-game events and

their corresponding notifications. For example, when a player proposes a treaty with

another player, an event is posted to the event bus. A listener might pick up this event

and send a notification mail to the player in question. The event bus is implemented

using a bounded queue data structure that automatically discards the oldest element

when it becomes full, in order to bound the amount of memory used. Here’s the

JUnit 3 test that the original developer wrote to check that the bounded queue

worked as expected.

public void testWorksAsItShould() {

int queueSize = 5;

BoundedQueue<Integer> queue =

new BoundedQueue<Integer>(queueSize);

for (int i = 1; i <= 20; i++) {

queue.enqueue(i);

}

while (!queue.isEmpty()) {

System.out.println(queue.dequeue());

}

Most likely the test was written before the days of CI, so the author never expected it to

be run more than once. They ran the test, manually verified that the numbers printed

to the screen matched what they expected, and then forgot about it.

But these days that kind of testing just doesn’t cut the mustard. We want our auto-

mated tests to guard against regressions, but the preceding test doesn’t. Even if you

accidentally change the behavior of the

BoundedQueue

class, the test won’t fail; it will

simply spit out a different set of numbers to the console.

Licensed to UNKNOWN UNKNOWN <cdjboy@163.com>

15Common legacy code traits and refactorings

Tests like this one are particularly toxic because they look and feel like a test, even

though they aren’t testing anything at all. They falsely inflate the project’s test count

and test coverage, giving developers a false sense of security. The solution is simple:

either fix the test by adding proper assertions, or delete it. (In this particular case, an

even better solution would be to delete both the test and the

BoundedQueue

class itself,

replacing it with a trustworthy third-party implementation such as Guava’s

Evicting-

Queue

BRITTLE TESTS

Good unit tests can prove valuable when refactoring, by providing assurances that the

behavior of given parts of the codebase is preserved. But if you find that tests often

break when you refactor, it may be a sign that the tests are too brittle. In this case, the

tests become a hindrance, as you end up spending more time fixing them than refac-

toring.

A common cause of fragility is unit testing at too fine-grained a level. Continuing

our

BoundedQueue

example, imagine you wrote a test for it like the following (this

time using JUnit 4 syntax).

@Test

public void wibbleFlagIsSet() throws Exception {

int queueSize = 5;

BoundedQueue<Integer> queue =

new BoundedQueue<Integer>(queueSize);

Field wibble =

Expose the private

field “wibble”

BoundedQueue.class.getDeclaredField("wibble");

wibble.setAccessible(true);

assertThat(wibble.getBoolean(queue), is(false));

Flag should

start off

false

for (int i = 1; i <= queueSize; i++) {

Fill the queue

queue.push(i);

}

assertThat(wibble.getBoolean(queue), is(true));

Flag should

now be true

}

This test uses Java reflection hackery to expose a private field and check its value. So if

you ever remove or rename this field in the course of a refactoring, the test will break.

In general there’s no need to write tests like

this. We should be testing the behav-

ior that components expose to each other, not any inte

rnal state they might be hold-

ing. If you ever find a test that’s accessing private members

of a class, or you find

yourself wanting to write one, it might be a hint that the class contains too much state

or is doing too much. You should consider splitting it into smaller classes that are eas-

ier to test.

RANDOMLY FAILING TESTS

A good test is completely deterministic, meaning that its result shouldn’t be affected by

changes in

CPU load, thread scheduling, network congestion, other tests running in

parallel, or any other external factor. But some tests don’t achieve this gold standard

Licensed to UNKNOWN UNKNOWN <cdjboy@163.com>

剩余154页未读，继续阅读

cdjboy

粉丝: 1
资源: 17

.NET Core新篇章：探索微服务、ASP.NET Core与EF Core

Microservices in .NET Core

电子书 asp.net 4.0 ebook_ASP_NET_4_Unleashed.pdf

ASP.Net Core3.0-AZ-EBook.pdf

ASP.NET教程(ebook)

ASP.net 技术揭秘(ASP.Dot.NET.2.0.Revealed.eBook)

eShopOnWeb：由Microsoft提供支持的示例ASP.NET Core 5.0参考应用程序，展示了具有整体部署模型的分层应用程序体系结构。 从docs文件夹下载eBook PDF

calibre-web:ASP.NET Core Web应用程序，用于浏览和下载Calibre数据库中存储的电子书

asp.net完全入门(Ebook)

ASP.NET Core 3.0 开发指南：从A到Z

asp.net 2.0 C# 圣殿祭司 ebook code

最新资源

eShopOnWeb：由Microsoft提供支持的示例ASP.NET Core 5.0参考应用程序，展示了具有整体部署模型的分层应用程序体系结构。从docs文件夹下载eBook PDF