Where to put ParseUrl() or similar function that works against a datastore, in ASP.NET MVC?

If you were to code a function/method th开发者_开发百科at 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.

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?