惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
aimingoo的专栏
aimingoo的专栏
博客园 - 叶小钗
H
Help Net Security
Microsoft Security Blog
Microsoft Security Blog
The Cloudflare Blog
S
SegmentFault 最新的问题
小众软件
小众软件
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 司徒正美
The GitHub Blog
The GitHub Blog
量子位
H
Hackread – Cybersecurity News, Data Breaches, AI and More
V
V2EX
Martin Fowler
Martin Fowler
博客园 - 【当耐特】
J
Java Code Geeks
D
DataBreaches.Net
云风的 BLOG
云风的 BLOG
F
Fortinet All Blogs
Blog — PlanetScale
Blog — PlanetScale
Last Week in AI
Last Week in AI

博客园 - 四眼蒙面侠

OpenAI 宣布破解纳维—斯托克斯:证明之外,为什么吵翻了? # 基于 Claude Code 的 Moltbook 心跳脚本:让你的 AI Agent 全自动参与社区 Moltbook 要把事情高大: AI 机器人的"身份证"来了 电视黑屏了,还在听吗?聊透 LG 智能电视隐私争议 Chrome 今年第六个零日漏洞:V8 认错了对象,而且真的有人在打 GLM-5.3 开放权重:该买机器把 AI 搬回家吗? 苹果没料到:Mac mini 怎么成了企业 AI 香饽饽 同一个模型,两道安全闸门:克劳德寓言 5.1 真正变了什么 AI 推荐的软件,到底是谁推荐的? GPT-6 Astra:破纪录之后,AGI 真的来了吗? OpenAI 的智能体,在德国老 wiki 上开了一块作弊黑板 一串会清空手机的密码,为什么可能换来五年牢狱? 作业高分,考试却跌两成:AI到底帮你学了什么? GitHub 上的第二张假面:一个大学生如何拦住会骗人的 AI 从十一到九十九,AI 创业公司为什么都爱叫 Labs? 卖十块板子,先交一千欧?欧洲包装新规为何难倒小卖家 玄戒 O3 跑分追上苹果,是真突破还是数字游戏? 当 AI 开始拆你的摄像头:桌面外设的安全边界正在消失 你用 AI 裁我,我就造个 AI CEO? 英伟达为什么想花 130 亿美元买下 Hugging Face? AI 已经会设计分子,为什么新药还没变快? 模型越强,为什么我们反而越不敢放手? DeepSeek Harness:为什么要把智能体的所有部件都做成插件 AI 让代码变便宜以后,工程师真正昂贵的是什么 加密的思考,也会被偷走吗?这篇论文真正发现了什么 一群模型,各干各的活:Nemotron 3.5 Lightning 和 Switchyard 到底解决什么 它真的“懂”你吗?用一杯咖啡理解大语言模型 买书、扫描、然后销毁:AI 训练的旧书去哪儿了? 七十GB与八十TB:当个人和科技巨头站上不同的法律天平 只读到小学五年级的 AI,能自己悟出高等知识吗?
【转】ASP.NET MVC 3 Service Location, Part 9: Model Binders
四眼蒙面侠 · 2011-01-25 · via 博客园 - 四眼蒙面侠

Model Binders

ASP.NET MVC 1.0 introduced the IModelBinder interface. Developers who implement this interface are responsible for creating models from values obtained from value providers. In ASP.NET MVC 3, we introduced a new interface (IModelBinderProvider) which allows developers to dynamically provide implementations of IModelBinder. We have made IModelBinderProvider instances findable via the dependency resolver.

Disclaimer

This blog post talks about ASP.NET MVC 3 Beta, which is a pre-release version. Specific technical details may change before the final release of MVC 3. This release is designed to elicit feedback on features with enough time to make meaningful changes before MVC 3 ships, so please comment on this blog post or contact me if you have comments.

Implementing IModelBinderProvider

In prior versions of MVC, developers could only register static mappings from types to model binder instances (throughModelBinders.Binders). While this satisfied simple uses, it made complex and powerful model binders a little more challenging to write.

When we decided to open model binding up for dependency resolution, we knew that we were going to need to introduce a layer of indirection, since model binders are usually only valid for a limited number of types (unless you are the default model binder).

We solved both problems by introducing a new interface:

public interface IModelBinderProvider {
    IModelBinder GetBinder(Type modelType);
}

Developers who implement this interface can optionally return an implementation of IModelBinder for a given type (they should return null if they cannot create a binder for the given type).

The system continues to rely on a “default model binder” if the system cannot find any appropriate model binder for the given type. You can change the default model binder by setting ModelBinders.Binders.DefaultBinder. Out of the box, this is set to an instance of DefaultModelBinder.

There are no implementations of IModelBinderProvider in MVC. However, there is a similar system in MVC Futures from MVC 2 (in the ModelBinding folder), and there are several model binder providers that could be used to spark ideas about writing providers for MVC 3, including model binder providers for arrays, binary data, collections, complex objects, and dictionaries.

Location: IModelBinderProvider

This is a “multiply registered” style service introduced in MVC 3. The static registration point for this service is at ModelBinderProviders.BinderProviders for non-DI users.

The logic in ModelBinderProviderCollection (which implements ModelBinderProviders.BinderProviders) consults the dependency resolver, calling GetSerivces(typeof(IModelBinderProvider)) and adding any services found to the list of statically registered services. Model binder provides are run in-order, with a “first one to provide a model binder wins” strategy, so registration order is important. The providers found in the dependency resolver will always run in the order they are returned from the resolver (and before the static registered providers).

What’s Next?

Next up we’ll look at the new Controller Activator service.