I am very much new to MVC4 ASP.NET and In-memory databases. I apologize if my answer is too basic and stupid. I have created an ASP.net MVC application that uses in-memory DB(SQLite3)by using
SQLiteConnection con=new SQLiteConnection(Data Source=:memory:;Version=3;New=True;);
I want to know that if database and its tables are created "in-memory", then how model and its classes will be generated so that i can use it in Controller/Views. In Memory database will be populated at runtime from certain XML.
EDIT
Here is how to create a table in memory
using (SQLiteConnection connection = new SQLiteConnection("Data Source=:memory:;"))
{
connection.Open();
connection.CreateModule(new SQLiteModuleEnumerable("sampleModule", new string[] { "one", "two", "three" }));
using (SQLiteCommand command = connection.CreateCommand())
{
command.CommandText ="CREATE VIRTUAL TABLE t1 USING sampleModule;";
command.ExecuteNonQuery();
}
using (SQLiteCommand command = connection.CreateCommand())
{
command.CommandText = "SELECT * FROM t1;";
using (SQLiteDataReader dataReader = command.ExecuteReader())
{
while (dataReader.Read())
Console.WriteLine(dataReader[0].ToString());
}
}
connection.Close();
}
here is the C# SQLite Library: http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
The low-tech way to solve this problem is to not generate model classes. Simply create them by hand to correspond to the part of the database you wish to work on in views. Remember that models are mostly meant for the use of the view - they should emphasize those things that the controller needs to pass to the view, and that the view needs to pass back to the controller. If they happen to mirror the database structure, then that's a bonus.
There may be some more-sophisticated ways of doing things, but I haven't used them. It's possible that you could create an Entity Framework Code First model, and use database migrations to actually create your in-memory tables. It's possible that you could then be lazy and use the exact same classes as the model that you pass to the views.
Better would be to have the Entity Framework classes worry about Entity Framework, and let the model classes worry about the views. Then use a tool like AutoMapper to copy data between the model passed to the view and the entity framework classes passed to the database.