page类 究竟是啥？page实例 和 html啥关系？

Posted 2023-04-25

很多asp.net教程上 提到了page类 ，说在vs中定义的aspx页面就是 page类的派生类，运行时会生成一个实例，我感到疑惑！
假设我定义了index.aspx，后台代码中 类的定义是：
public partial class index:Page

...........


一般说来，定义类无非就是定义类的方法和数据字段，可是，我写的index.aspx页面中不仅 有类index的方法代码（例如 page_load），前台还有html代码和web控件，

难道这些html代码和web控件 也属于index类的一部分吗？在C#语言中，类的定义不能包括html代码吧？

Page类确实定义了aspx以及.cs文件里的class，而.cs继承Page类后你就可以调用Page类里的一切东西，而html所有的元素、服务器控件等也都封装到Page类里了，所以当你在.aspx写html元素、服务器控件在.cs里也能获取到。不是这些html代码和web控件也属于你定义的index类，而是属于Page类，你的index类继承了Page类，那么也就能使用Page类里的所有东西，另外你在index类中也同时可以有自己的东西，就这样理解。你可以看看类的封装、继承等面向对象编程来理解。希望我的回答对你有帮助，谢谢 参考技术A Aspx页面都继承于Page类，都是Page类的子类。
Page类实例有处理页面类的一些基本的静态属性、属性、静态方法、方法。
Html是Aspx页面类处理逻辑关系的模板和处理后的模板实现。 参考技术B 自己架服务器!想怎么搞就怎么搞!
关于域名 下载花生壳3.9,申请免费的域名!呵呵

如果对架服务器有什么疑问欢迎到留言!追问

垃圾！

“有效”究竟是啥意思

【中文标题】“有效”究竟是啥意思

【英文标题】：What exactly does "effectful" mean“有效”究竟是什么意思

【发布时间】：2016-01-27 23:09:40

【问题描述】：

我一遍又一遍地阅读有效这个词，但我仍然无法明确定义它的含义。我假设正确的上下文是有效的计算，但我也看到了有效的术语values)

我曾经认为有效意味着有副作用。但是在 Haskell 中没有副作用（在某种程度上 IO 除外）。仍然到处都有有效的计算。

然后我读到 monad 用于创建有效的计算。我可以在State Monad 的上下文中理解这一点。但我看不到 Maybe monad 的任何副作用。一般来说，在我看来，包装类似函数的东西的 Monad 比只包装一个值的 Monad 更容易被视为产生副作用。

当谈到 Applicative 函子时，我更加迷茫了。我总是将应用函子视为map 具有多个参数的函数的一种方式。我在这里看不到任何副作用。或者有效果的和有效果的有区别吗？

【问题讨论】：

也许有用：slpopejoy.github.io/posts/Effectful01.html 他将 effectful 定义为： 1. 实际副作用 (IO) 2. 看起来像副作用的东西（状态、作家等） .) 3. 在函数调用中持续存在的上下文（Reader、State 等） 4. 非本地控制流（Maybe、Either）。

大多数 monad 是根据纯计算定义的，但从程序员的角度来看，通常将 State s a 视为可以读取/写入状态 s 的命令式子例程有副作用，最后产生一个a。就算是纯的，有时候假装不是也很方便。在主题上，我想说的是 effectful 和 with effects 的意思是一样的，即使它们有时被广泛地应用于包装在任何 monad/applicative 中的值，即使它们没有模拟副作用。

我在关于Traversables 的问题的评论中找到了一个很好的答案。有人问这个问题“‘效果’这个词是什么意思？” @missingfaktor 给出了一个非常好的答案，简而言之：“这意味着 Functor 的结构信息，即非参数化的部分”。 Here 是完整的答案。

【参考方案1】：

side effect 是与其环境的可观察交互（除了计算其结果值）。在 Haskell 中，我们努力避免具有这种副作用的函数。这甚至适用于IO 操作：当评估IO 操作时，不会执行任何副作用，只有在IO 值中规定的操作在main 内执行时才会执行。

但是，当使用与组合计算相关的抽象时，例如应用函子和 monad，在某种程度上区分实际值和“剩余”（我们通常称之为“效果”）是很方便的。特别是，如果我们有一个类型为f 的kind * -> *，那么在f a 中，a 部分是“价值”，而任何“剩余”都是“效果”。

我故意引用这些术语，因为没有精确的定义（据我所知），它只是一个口语定义。在某些情况下，根本没有值，或者有多个值。例如对于Maybe，“效果”是可能没有值（并且计算被中止），对于[]，“效果”是有多个（或零）值。对于更复杂的类型，这种区分可能更加困难。

“效果”和“价值”之间的区别并不真正取决于抽象。 Functor，Applicative 和 Monad 只是给我们工具，我们可以用它们做什么（Functors 允许修改内部值，Applicatives 允许组合效果，Monads 允许效果依赖以前的值）。但是在Monads 的上下文中，创建一个正在发生的事情的心理画面会更容易一些，因为单子动作可以“看到”先前计算的结果值，正如

(>>=) :: m a -> (a -> m b) -> m b

operator：第二个函数接收a类型的值，所以我们可以想象“之前的计算产生了一些影响，现在有了它的结果值我们可以做一些事情”。

【讨论】：

您能详细说明一下Applicatives的“效果”吗？毕竟有一篇论文“Applicative Programming with effects”，我一直不太理解标题（我相信我理解 applicatives）

@MartinDrautzburg 正如我所写，“效果”和“值”之间的区别是由实际数据类型给出的，而不是我们用来操作它的抽象。例如，对于Maybe，“效果”总是可以中止计算，无论我们使用 Applicative 还是 Monad（或其他）接口。如果您在Maybe 中写入f <$> a <*> b <*> c，则a、b 或c 中的任何一个都可以使用Nothing 中止计算，这就是它的“效果”。应用接口允许组合效果（对于Maybe，它意味着在第一个Nothing 上中止），但不允许效果依赖于先前的值。

【参考方案2】：

为了支持Petr Pudlák's answer，这里有一个关于那里所支持的更广泛的“效果”概念的起源的论点。

“有效编程”一词出现在 McBride 和 Patterson 的 Applicative Programming with Effects 的摘要中，该论文介绍了应用函子：

在本文中，我们介绍了Applicative函子——一种有效编程的应用风格的抽象表征，弱于Monads，因此更广泛。

“Effect”和“effectful”出现在论文的其他几个段落中；这些事件被认为是不起眼的，不需要明确澄清。例如，这句话是在 Applicative 的定义出现后（第 3 页）：

在每个示例中，都有一个类型构造函数f，它嵌入了通常的 值的概念，但支持其为通常的应用语言赋予意义的独特方式 [...] 我们相应地引入了 Applicative 类：

[Applicative 的 Haskell 定义]

这个类概括了 S 和 K [即the S and K combinators，出现在 Reader/function Applicative 实例中] 从线程化环境到线程化效果。

从这些引用中，我们可以推断出，在这种情况下：

效果是Applicative 线程“一般”的东西。

效果与给定 Applicative 实例的类型构造函数相关联。

Monad 也处理效果。

根据这些线索，我们可以将这种“效果”的用法至少追溯到Wadler's papers on monads。例如，这是 函数式编程的 Monads 第 6 页的引述：

一般来说，a → b 类型的函数被 a 类型的函数替换 → M b。这可以理解为一个接受 a 类型参数的函数 并返回一个 b 类型的结果，可能还有一个被捕获的附加效果 M。这种效果可能是作用于状态、生成输出、引发异常或你有什么。

来自同一篇论文，第 21 页：

如果 monad 封装了效果并且列表形成了一个 monad，那么列表是否对应于某种效果？确实如此，它们对应的效果就是选择。可以将 [a] 类型的计算视为提供值的选择，列表的每个元素一个值。 a → b 类型的函数的一元等价物是 a → [b] 类型的函数。

这里的“对应某种效果”是关键。它与摘要中更直接的主张联系起来：

Monad 提供了一个方便的框架来模拟其他语言中的效果，例如全局状态、异常处理、输出或非确定性。

单子可以用来表达在“其他语言”中通常被编码为副作用的事物——也就是说，正如 Petr Pudlák 在他的回答中所说，“与 [一个函数的] 环境（除了计算它的结果值）”。通过转喻，这很容易导致“效果”获得第二个含义，比“副作用”更广泛——即，通过类型构造函数引入的任何东西，它是一个 Monad 实例。随着时间的推移，这一含义被进一步推广到涵盖其他函子类，例如 Applicative，如 McBride 和 Patterson 的工作所示。

总的来说，我认为“效果”在 Haskell 用语中有两个合理的含义：

“字面”或“绝对”之一：效果是副作用；和

“概括”或“相对”的一种：效果是一种功能性上下文。

有时，当每个相关方都隐含地假设“效果”的不同含义时，会发生可以避免的术语分歧。另一个可能的争论点是在单独处理Functor 时谈论效果是否合法，而不是像Applicative 或Monad 这样的子类（我相信这样做是可以的，与@987654325 一致@)。

【参考方案3】：

在我看来，“副作用”是正常功能无法做到的。换句话说，除了返回一个值之外的任何东西。

考虑以下代码块：

let
  y = foo x
  z = bar y
in foobar z

这个调用foo，然后调用bar，再调用foobar，三个普通函数。很简单，对吧？现在考虑一下：

do
  y <- foo x
  z <- bar y
  foobar z

这也调用了三个函数，但它也在每对行之间无形地调用(>>=)。这意味着会发生一些奇怪的事情，具体取决于函数运行的 monad 类型。

如果这是身份单子，则不会发生任何特殊情况。 monadic 版本与纯版本完全相同。没有副作用。

如果每个函数都返回一个Maybe-something，那么如果（比如说）bar 返回Nothing，整个代码块就会中止。普通功能无法做到这一点。 （即，在纯版本中，没有办法阻止foobar 被调用。）所以这个版本做了纯版本不能做的事情。每个函数都可以返回一个值或中止块。这是副作用。

如果每个函数都返回一个内容列表，则代码会针对所有可能的结果组合执行。同样，在纯版本中，没有办法让任何函数使用不同的参数多次执行。所以这是一个副作用。

1234563同样，你不能用纯函数做到这一点，所以这是一个副作用。

在IO monad 中，你有各种有趣的效果。您可以将文件保存到磁盘（文件基本上是一个巨大的全局变量），甚至可以影响在其他计算机上运行的代码（我们称之为网络 I/O）。

ST monad 是 IO monad 的缩减版。它允许可变状态，但自包含计算不能相互影响。

1234563 >

continuation monad 允许您打破人们的想法！ 可以说，这对于纯函数是可能的...

【讨论】：

我同意你赋予延续单子的“效果”。其他的，我不和你在一起。 “do”表示法隐藏了对 >>= 的调用这一事实并不能使其有效，因为没有这种语法糖，表达将同样有效，但不会隐藏 >>=。它根据 monad 的类型做不同的事情这一事实归功于 monad 是一个类型类。所有类型类都会发生这种情况，无论是否有效。

好吧，很明显IO、ST 和STM 只能通过普通的 Haskell 代码无法做到的低级工作来实现。严格来说，所有其他 monad 都只是无形运行的纯代码。但是将它们认为它们是有效的计算仍然很有用。在某种程度上，这只是一个观点问题。

同意兰花。有效语义是 monad 的预期面向用户的语义，Haskell 程序员在实践中考虑效果。通过纯函数实现通常就是一个实现细节。无论如何，停留在纯粹的功能级别的表示是有点武断的，当我们可以进一步研究机器代码时，尽管源表示是纯粹的，但它具有许多可变更新。

一个广泛的主题是计算m :: f a是纯的当且仅当存在x :: a使得m = pure x。从这个意义上说，任何不纯粹的东西都有“副作用”。当f ~ Identity 时，每个计算都是纯粹的，因为创建Identity a 类型的东西的唯一方法是将Identity = pure 应用于a 类型的东西。

@dfeuer，你的回答看起来很有趣，但我不太明白。 @Orchid&Andreas：我理解你的（好的）观点，“有效”是指一种看待事物的方式，而不是你可以在代码中发现的东西。但我仍然不明白什么样的看待事物的方式才能保证术语有效。

【参考方案4】：

“效果是一个非常模糊的术语，这没关系，因为我们试图谈论语言之外的东西。效果和副作用不是一回事。效果很好。副作用是错误。

它们的词汇相似性真的很不幸，因为这导致很多人在阅读它们时将这些想法混为一谈，并且人们使用一个而不是另一个，从而导致很多混乱。”

更多信息请看这里：https://www.slideshare.net/pjschwarz/rob-norrisfunctionalprogrammingwitheffects