I have an open source application (here)
This application get a character or a sentence and give some unicode information about it.
Iuse Unicode Character Database which provided by Unicode.org this is a XML document (130MB)
At first I embed this XML to my DLL but I don't know is it a good approach or no. because DLL size growth just because of this XML document. I can use it like any other resources but usercan see it.
What Should I do? What is the best pattern for this? and Why ?
TIA
What is the size if you compress the file? If the savings are significant, use a compressed resource, uncompress the resource to a memory stream then load stream into XML document.
I think XML is not the way to go here. Especially when performance is critical. If it's that big consider switching to embedded dbs (e.g. SQLite or anything else).
To read more about XML vs SQLite check this question: Xml or Sqlite, When to drop Xml for a Database?
XML is a data exchange format. Since you already considered to embed the XML file into your DLL, probably nobody will actually need the format to be XML. What about just extracting the relevant data from the XML file and storing that as a resource in your DLL? First, it saves you space, and second, you can already organize the data in the way you will need it later.
I guess an embedded resource is a good option if you're happy to re-compile and re-deploy every time there is a change; also, just because you might be happy to do this doesn't mean everyone will be :)
A very common approach is to abstract out any kind of data access behind an interface; if you did this you'd be able to let users choose which implementation they wanted (assuming you provided a couple) and it would let them write their own. In terms of patterns this is Dependancy Inversion (also known as Inversion of Control).
If you drive the instansiation of the provider via config (i.e: using a Factory) you'll be able to switch providers without having to re-deploy the main part of the app (the part that consumes the data). So, you can have as many different providers as you want: an XML read-from-file provider, a SqlLite data provider, a web service / cloud based provider, etc.
I like Rolands approach - you could build that as an implementation of the provider too (read file into memory, respond to queries from memory - fast).