在信息系統中，很多的信息都是有標準化，所謂標準就是實現定義的一些規範，根據這個規範可以在多個實體之間進行數據的共享，以避免溝通中的歧異問題。
數據字典就是標準化中的一個重要組成部分。
關於數據字典的定義，版本有很多，在不同的場合中可能有不同的含義，這裏特指的是：一個屬性可能具有的幾個值。比如：性別的字典爲男、女等等，主要用來進行數據歸類（統計）。
數據字典的解決方案有很多種，這裏僅討論其中兩種。
一、字典數據本地化方案
在B/S中，就是將所有字典數據都創建爲js文件，select、combo組件的option、data就從js中取。
每次更新, 維護字典項時，自動創建或更新對應的字典js文件。然後通知客戶端來更新對應的js文件；
Strength：一次加載，重複使用。速度快，服務器壓力小；
Weakness：不好維護，不利於代碼生成；（或者說生成、使用比較複雜）、字典數據的安全性。
關於js文件的版本控制，可以採用下面的方式：
1、在引入字典script的時候爲其增加id屬性；
2、在script src中添加參數；
3、每次重新創建js之後，修改這個參數值，這樣客戶端在加載js時，如果發現參數變化，就相當於不同的js，所以會重新加載；
但是，這樣就意味着每次build 字典js之後，都需要更新所有引入這個js的頁面文件。
另外，一些場合中，字典項需要根據條件進行過濾。這種方式需要在設計js字典格式時有靈活的定義。
二、服務器端模式
數據字典只存在於服務器端，每次用戶請求某個包含字典項的頁面，都從服務器端檢索，並返回數據。
Strength:
便於維護（字典變化不會影響到客戶端的使用，無序影響其他頁面文件編碼）
靈活（可靈活地定義過濾邏輯）
數據保存在服務器端，安全性相對較好；
Weakness:
每次都需要加載（佔用網絡帶寬和服務器資源）；
每次加載造成響應速度不如前者好；
爲了提高速度，可以將數據字典進行緩存，在數據更新之後更新緩存（需要注意分佈式緩存中的數據同步性問題，否則在一些應用中這個問題很Yao Ming）
這兩種方案都能比較好地解決數據字典的問題，也各有優缺點，需要根據用戶的需求進行選擇使用。
