在 ASP.NET MVC 中，将 ParseUrl() 或针对数据存储的类似函数放在哪里？
如果您要编写一个函数/方法，对于输入的字符串或 slug（例如在创建或编辑视图中），进入数据存储并检查该字符串或 slug 是否存在，并在本例中创建指向它的链接，在哪里你放了吗？
例如，我们的“创建”或“编辑”表单上有一个“链接”文本框。我有一个 jQuery 自动完成连接到它，它检索现有的页面 slugs。如果用户决定选择其中之一，我们将根据页面控制器创建一个指向我们网站内内容的链接，如下所示：
~/Page/Display/some-slug
或者只是
~/Page/some-slug
如果用户决定不选择任何内容并输入例如 www .google.com，我们在 ParseUrl() 中捕获它，使用 http://... 等对其进行格式化，然后像这样存储它。
该函数的代码没有问题，我目前正在模型绑定器中运行它。然而，由于模型绑定器中 DI 的奇怪、令人困惑和相反的做法，我想将其移到其他地方。另一个原因是从模型绑定器中删除数据访问代码。
问题是 - 将这样的功能转移到哪里？如果可能的话，我想避免在各种控制器操作中重复 ParseUrl() 调用。
If you were to code a function/method that would, for entered string or slug (for instance in Create or Edit view), go into datastore and check whether that string or slug exists and in this case create a link to it, where would you put it?
For instance, we have a "Link" textbox on our Create or Edit form. I have a jQuery autocomplete wired to it, which retrieves existing Page slugs. If a user decides to select one of them, we would create a link that points to the content within our site, based on the Page controller, like this:
~/Page/Display/some-slug
or just
~/Page/some-slug
If, however, user decides not to select anything and inputs for instance www.google.com, we catch it in our ParseUrl(), format it with http://... etc. and store it like that.
The code for the function is no problem and I have it working currently in a Model Binder. However, due to strange, confusing and opposing practices with DI in Model Binders I would like to move it somewhere else. Another reason would be to remove dataccess code from Model Binders.
The question is - where to move such funcionality? If possible, I would like to avoid repeating ParseUrl() calls across various controller actions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
1) 实施它，使其对您和您的团队有意义。
- 或 -
2) 将其保留在原处，因为它已经在工作了。
移动它是否会让您的应用程序变得更好，您的客户会更满意，更快地满足最后期限吗？
如果你敢使用错误的扩展点，没有神奇的 Asp.net MVC 雷神会从天而降来打击你。没有人会称你为白痴。人们可能不同意，但这种情况确实发生了。可以“全力以赴”并在架构纯粹之前完成工作。
“然而，由于模型绑定器中 DI 的奇怪、令人困惑和相反的做法”
这到底意味着什么？
1) Implement it so it makes sense to you and your team.
-or-
2) Leave it where it is because its already working.
Is moving it going to make your app better, will your customers be happier, deadlines met faster?
There is no magic Asp.net MVC thunder-god that descends from the heavens to smite you if you dare use the wrong extensibility point. Nobody is going to call you an idiot. People may disagree, but that happens. Its ok to "go for it" and get things done before being architecturally pure.
"However, due to strange, confusing and opposing practices with DI in Model Binders"
What does that even mean?