First read the "MVC Program implementation autocomplete function" http://www.cnblogs.com/insus/p/3546255.html it is implemented using jquery to implement text box input text, the drop-down list appears, automatic completion and selection function.
Trust in your developed MVC application, there is more than one unique feature of this autocomplete. If there are multiple, or constantly new overtime, in your handlers directory, there will certainly be multiple ashx files to support. Each additional one will replicate and then modify it. Because this ashx is processed within the individual data of different homogeneous.
So let insus.net remember, can all AutoComplete only share a ashx file? Whether it can be solved and realized, I wish to try.
This article will use techniques and knowledge such as interface (interface), Reflection (Reflection).
To be more vivid and demonstrative, Insus.net adds another AutoComplete, based on the previous example:
Open two handlerx.ashx files, compare and discover:
Only the highlighted ones are different, and that is the instantiation of their respective classes.
It doesn't matter, you know. NET programming, you can abstract or interface them. The interface is used in this insus.net.
In MVC, under the interfaces directory of the application, create a iautocompletable interface:
interface implementation, the program in the future AutoComplete function implementation, in the entity class to implement this interface, but now the implemented entity, respectively open it to re-implement can:
See how PinYinEntity.cs was changed:
Additional AbbreviatorEntity.cs classes:
Two classes are implemented as interfaces and return the interface function data type DataTable. When new features such as this are added, the Commentout method code will not have to be written anymore.
See here, we are in the two classes, each class is commentout in the syntax, another sentence is crossed out, it means to convert the DataTable to list<t>. I can go back to see the Handlerx.ashx file, in the #25~ #26行代码, it means to put list<t> serialized object.
Based on these two codes, Insus.net decides to write another common function integration, which is a way to serialize the DataTable:
Below insus.net in the handlers directory, write a autocomplete.ashx file that will replace the previous Handlerx.ashx file:
In the future, all jquery would like to implement the AutoComplete function, only need to reference this file. This file has more than one parameter added, Insus.net is distinguished by the data table name, and of course you can define this parameter as you think.
String tableName = context. request["TableName"];
This ashx file also applies reflection (Reflection), which is reflected to classes that have implemented interface IAutoCompletable.cs based on the parameters passed in.
The next job is to modify the two views that exist, with each view changing only one line of code:
Another view:
In the future, when you add another new AutoComplete feature, there is a view that references this sentence:
URL: "/handlers/autocomplete.ashx?tablename=xxx&prefix=" + request.term,
where xxx is the reference value that represents you.
Finally, a real-time operation demo is attached:
The following is an MVC application that exercises the latest source code and database backup files.
The program is the. NET Framework 4.5, and the database is SQL Server 2012:
Http://download.cnblogs.com/insus/MVC/InsusMVCSiteCS_2014_Feb14.rar