In a solution, I have two DALs. Each accesses a different server.
The first server/database contains a table that will provide database names.
var db = "db_1"; // can be db_1, db_2, db_3, etc.
The second server contains many databases - each containing an identical table that needs to be queried.
I need to be able to dynamically switch contexts depending upon the db value. I'd like to be able to pass the db var to a business layer that returns/uses the correct Context.
You can create two models for this. One for your database containing the tables that provide the database names, and the other for the other databases.
If you are using the db first approach, your context object will be created with a default connection string. Since it is a partial class you can extend it to take a connection string like so...
public partial class MyContext
{
public MyContext(string nameOrConnectionString) : base(nameOrConnectionString)
}
This is where at runtime you will pass the connection string of the server/database you pulled from the first context. Something like this is what it will look like...
...
using(var dbNameContext = new DatabaseNameContext())
{
var dbName = dbNameContext.DBNames.FirstOrDefault(dbn => dbn.Name == "db1");
var connectionString = "metadata=res://*/Database..." + dbName.Name;
using(var dbContexts = new MyContext(connectionString))
{
var MyDataList = dbContexts.Data.ToList();
}
}
Obviously you should fix the connection string to be like your own and place the dbName where it belongs in the connection string.
You should make sure you have a plan intact for keeping all of the different tables in different databases the same so that the model is accurate. Otherwise you will get RTEs.
Related
I'm trying to declare DbSet in my Databases Context class.
Because I don't which class (Entity Framwork Class) user calls.
That's why I want to declare the DbSet with dynamic.
I would try to have everything explicitly defined in your context. There's a lot of functionality baked into that property declaration, not the least of which is the design-time benefit of having types.
There are many techniques for dynamic querying, but I'll post one that I've used in the past for dynamically querying lookup tables.
public List<LookupItemDTO> LoadItems(int lookupId)
{
//nothing special here, just map the lookup id to a name
var lookupRepo = new LookupRepository<LookupDefinition>(uow);
var lookup = lookupRepo.Find(id);
//map the lookup's name from the table to a type. This is important DO NOT ACCEPT A TABLE NAME FROM THE USER.
var targetType = Type.GetType("MyApp.DomainClasses.Lookup." + lookup.Name + ",MyApp.DomainClasses");
// this is an optional extra step but it allows us to instantiate an instance of our repository to ensure that business rules are enforced
var lookupType = typeof(LookupRepository<>).MakeGenericType(targetType);
dynamic LookupTable = Activator.CreateInstance(lookupType);
//just some pattern nonsense to wire up the unit of work
LookupTable.SetupUOW(uow);
//make sure to cast it into something you can work with ASAP
var data = ((IQueryable<LookupTableBase>)LookupTable.All).OrderByDescending(l => l.IsVisible).ThenBy(l => l.SortOrder);
var list = from li in data
select new LookupItemDTO
{
Id = li.Id,
Description = li.Description,
Display = li.Display,
SortOrder = li.SortOrder,
IsVisible = li.IsVisible
};
return list.ToList();
}
The key here is that you can dynamically query tables, but it's better to do it at a higher level. Also, have some kind of indirection between you and your user's input. Let them select a table from a list, use the ID from that table to look up the name. My solution here is the have a lookup table definition table. Any dynamic queries start there first and then values from that definition table are used to build the necessary types.
My project specifications are ASP.net MVC3 Application with Entity Framework.
The problem is that Customer wise the database will be created. Individual application individual database is working fine for me.
But i want a single application and multiple databases should be used with that.
How to achieve the same?
Instead of creating your entity connections using the default constructor and web.config-driven connection string, you need to manually build the entity connection string and feed it into it on construction using one of the other constructors. There's usually one that takes a string, and another that takes an EntityConnection instance as well.
If the only thing that changes is the name of the database, then you can probably get away with a format string - where you perhaps take the one that's currently in your web.config - which will look something like this:
metadata=res://*;provider=System.Data.SqlClient;provider connection string="Data Source=[server];Initial Catalog=[db];User ID=[user];Password=[password]"
Note - [server], [db], [user] and [password] here are placeholders.
And simply replace the [db] with {0}.
Then - assuming you can derive a database name from a user you might do something like this following:
public string BaseConnectionString {
get{
//TODO: Get base connection string - can just bake in the constant string with
//with the format placeholder. A better thing would be to add it as an
//AppSetting in web.config
}
}
//this now becomes you're primary way of getting a database connection for a user.
public MyEntities GetEntities(User user)
{
var eConnectionString = GetConnectionString(user);
return new MyEntities(eConnectionString);
}
public string GetConnectionString(User user)
{
var dbName = get_db_name_for_user(user);
return string.Format(BaseConnectionString, dbName);
}
This is but one way to achieve this. In an IOC environment it would be possible to hide all of this behind a simple Resolve<> call.
I have a little project where I'm running MVC3.
I use LINQ to fetch data from the database.
I built my project with the same architectural design as the premade examples that come with MVC3.
In such a project, the application is split up and in this topic I want to focus on the Model.cs files. I have one for each controller at the moment, So as an example, I have a HighscoreController.cs and a HighscoreModels.cs. In the model class I define a Service class that has a reference to a datacontext and some methods that use this datacontext to query the database.
Now i ran into the problem that some of these methods are executing the same queries, and therefore I wanted to make a central point of access to the database so I thought I would implement the Repository Pattern, and so I did.
So instead of having a reference to a datacontext in the Service class I now have a reference to the repository as such:
private IRepository _repository;
public HighscoreService()
: this(new Repository())
{ }
public HighscoreService(IRepository repository)
{
_repository = repository;
}
Now the database calls are handled within the repository and the repository is used from the Service class through the _repository reference.
My repository is built like this:
public class Repository : IRepository
{
private MyDataContext _dataContext;
public Repository()
{
_dataContext = new MyDataContext();
}
public Member MemberByName(string memberName)
{
Member member = CompiledQueries.MemberByName(_dataContext, memberName);
return member;
}
}
The problem I face appears when I try to use DataLoadOptions in combination with this repository pattern.
Because when you use dataloadoptions, you must not have made previous queries on the datacontext before a new dataloadoptions is applied to it. And since my repository reuses the datacontext throughout all methods, this does not work out at all.
I have been trying 2 things, one is recreating the datacontext within every methods, by way of the using statement, to make sure that the datacontext is refreshed every time. But then I get problems when I have fetched the result from the repository back into my model and the scope runs out inside the repository pattern, as the using statement ends, which means that the result cannot be used with e.g. .Count() or .ToList() because the datacontext that supplied me the data has been terminated. I also tried another solution where it uses the same datacontext throughout the whole repository, but makes a new instance in each method that uses dataloadoptions. This felt very dirty ;)
So can anyone give me a suggestion on how to use DataLoadOptions with the repository pattern? and avoid the problems I just described. Or should i not use dataloadoptions and choose another way of doing it? The reason i use DataLoadOptions by the way, is that I want to have some data from related tables.
As a little question on the side: In the code example above you can see that I have placed CompiledQueries within a .cs file of its own. Is this a bad design? Are there any guidelines for where to put compiled queries in an MVC application?
Thanks for reading and hope there are some answers for my questions ;) thanks a lot in advance. If you need more information, just ask.
I am by no means an expert on DataLoadOptions, but from your question and what I've read about it, it seems that you need to use it for eager loading. In reference to this:
"Because when you use dataloadoptions, you must not have made previous queries on the datacontext before a new dataloadoptions is applied to it."
.. to me this sounds like a shortcoming or design flaw with DataLoadOptions (I personally use Entity Framework, not LINQ to SQL). While I do think it's a good idea to have a single data context per HTTP request as offered in the first 2 comments by ngm and CrazyCoderz, I don't think this will solve your problem. If you want to reuse a single data context within a single HTTP request, as soon as you execute the first query, it sounds like you will be unable to set the DataLoadOptions on the data context to a new value.
I saw a presentation at vslive vegas where the presenter offered one of the solutions you mentioned, creating a new data context in each repository method. What you would have to do here is call ToList() or ToArray() before terminating the using statement and returning the method result(s).
As you mentioned, this would make objects not pre-loaded into the enumeration inaccessible after the method returns. However, if you already have the query executed and converted to a List, Collection, Array, or some other concrete IEnumerable, you don't need access to the Count() or ToList() methods any longer. Instead, you can use Array.Length or List.Count or Collection.Count properties.
What else is stopping you from creating a new data context in each repository method? Meaning, what do you need the data context for, after executing the repository method, that you can't get because it's been disposed of?
Reply to comments
For your first query, can you do this?
public Member GetSomeRandomMember()
{
Member[] members = null;
using (var context = new MyDataContext())
{
// execute the query to get the whole table
members = context.Members.ToArray();
}
// do not need to query again
var totalRows = members.Length;
var skipThisMany = PerformRandomNumberComputation(totalRows);
return members.Skip(skipThisMany).FirstOrDefault();
}
Granted that might not be optimal if your Members table has a lot of rows. In that case you would want to execute 2 queries -- 1 to count, and a second to select the row. You could achieve that by opening 2 contexts:
public Member GetSomeRandomMember()
{
using (var context1 = new MyDataContext())
var totalRows = context1.Members.Count();
var skipThisMany = PerformRandomNumberComputation(totalRows);
Member member = null;
using (var context2 = new MyDataContext())
member = context2.Members.Skip(skipThisMany).FirstOrDefault();
return member;
}
For the second part of your comment, I'm not sure I get what you are talking about. The fetching of the data and the making changes to it should all come in a single operation with a single context anyways:
public void SaveMember(int id, string email, bool isSuspended)
{
using (var context = new MyDataContext())
{
var member = context.Members.Single(m => m.Id == id);
member.Email = email;
member.IsSuspended = isSuspended;
context.SaveChanges(); // or whatever the linq to sql equivalent is
}
}
If you want to pass the whole entity to the repository method, you should still query it out so that it is attached to the correct context:
public void SaveMember(Member member)
{
var memberDto = member;
using (var context = new MyDataContext())
{
member = context.Members.Single(m => m.Id == memberDto.Id);
member.Email = memberDto.Email;
member.IsSuspended = memberDto.IsSuspended;
context.SaveChanges(); // or whatever the linq to sql equivalent is
}
}
I'm following Steve Sanderson's example from this ASP.NET MVC book on creating a model by hand instead of using diagramming tools to do it for me. So in my model namespace I place a class called MySystemModel with something like the following in it
[Table(Name="tblCC_Business")]
public class Business
{
[Column(IsPrimaryKey=true, IsDbGenerated=false)]
public string BusinessID { get; set; }
// this is done because Business column and Business have interfering names
[Column(Name="Business")] public string BusinessCol { get; set; }
}
This part of it is all fine. The problem however is returning multiple result sets from a stored procedure, but mixing and matching SQL with LINQ modelling. We do this because the LINQ to SQL translation is too slow for some of our queries (there's really no point arguing this point here, it's a business requirement). So basically I use actual SQL statements along with my LINQ models in my "repository" like so:
public IEnumerable<MyType> ListData(int? arg)
{
string query = "SELECT * FROM MyTable WHERE argument = {0}";
return _dc.ExecuteQuery<MyType>(query, arg);
//c.GetTable<MyType>(); <-- this is another way of getting all data out quickly
}
Now the problem I'm having is how to return multiple result sets as I'm not extending DataContext, like so:
public ContractsControlRepository()
{
_dc = new DataContext(ConfigurationManager.ConnectionStrings["MyConnectionString"].ToString());
}
This link describes how multiple result sets are returned from stored procedures.
[Function(Name="dbo.VariableResultShapes")]
[ResultType(typeof(VariableResultShapesResult1))]
[ResultType(typeof(VariableResultShapesResult2))]
public IMultipleResults VariableResultShapes([Parameter(DbType="Int")] System.Nullable<int> shape)
{
IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), shape);
return ((IMultipleResults)(result.ReturnValue));
}
So how do I turn this into something that can be used by my repository? I just need to be able to return multiple result sets from a repository which contains DataContext, and doesn't extend it. If you copied and pasted the previous extract into a repository like I've got it will just state how ExecuteMethodCall isn't available, but that's only available if you extend DataContext.
Resources
Guy Berstein's Blog
Every time I ask a question that has been hindering me for days on end I end up finding the answer within minutes. Anyway, the answer to this issue is that you have to extend DataContext in your repository. If like me you're worried about having to specify the connection string in every single controller then you can change the constructor in the repository class to something like this:
public ContractsControlRepository()
: base(ConfigurationManager.ConnectionStrings["AccountsConnectionString"].ToString()) { }
This way when you instantiate your repository the connection is set up for you already, which gives you less to worry about, and actually centralizes specifying the connection string. Extending DataContext also means you have access to all of the protected methods such as ExecuteMethodCall used for calling stored procedures and bringing back, if you will, multiple result sets.
how should i load the table "Setting" into an asp.net mvc so that i can use it as a reference setting for the whole application.
Is there anyway to save the memory and usage to do this problem? In my understanding, if i have settings in database, i will have to make the program load the table into a variable, then call out. But is there anyway to save a query from being waste?
im using linq to sql
Thanks
Yes, if you use a proper ORM layer, like NHibernate (for instance with Fluent), which can cache the calls (SQL queries) to the settings table for you fully automatically. And you'll handle the tables without any SQL, only as calls to methods of classes.
However, it requires learning NHibernate, which can take a bit getting used to.
It is not possible to get the data of the Settings table from the database without issuing a query to the database. But you can prevent the tedious use of mapping the result to objects by using an ORM.
If you take both NHibernate and FluentNHibernate, it looks something like this for MS SQL Server 2008:
// this depends on your implementation, I assume a Settings class with
// simple getters and setters that map directly to the table. Use
// Fluent to do the mapping (see link) automatically through AutoMappings
// example of using AutoMappings plus configuration of linking to DB:
ISessionFactory sessionFactory = Fluently.Configure()
.Database(
MsSqlConfiguration.MsSql2008
.ConnectionString(c =>
c.Server("123.12.21.321")
.Database("db_name")
.Username("db_user_with_access_to_db")
.Password("passwordhere")
)
)
.Mappings(m =>
m.AutoMappings.Add(AutoMap.AssemblyOf<Logo>()
.Where(t => t.Namespace == "YourNamespace.Entities"))
)
.BuildSessionFactory();
// example of a Settings class:
public class Settings
{
public int Id { get; private set; }
public int BackgroundColor { get; set }
// etc
}
// example of getting a session, retrieving data, changing/saving data
ISession session = sessionFactory.OpenSession(); // session for getting data from DB
Setting mySetting = session.Get<Setting>(someId);
mySetting.BackgroundColor = 0xAA44DD;
var transaction = session.BeginTransaction();
session.SaveOrUpdate(mySetting);
transaction.Commit();
// how it looks like if you use Generics and a little Dao class to wrap it all up:
Dao<Settings> daoSettings = new Dao<Settings>();
Settings someSettings = daoSettings.Get(someIdHere);
Settings userSettings = daoSettings.Get(new User("John"));
List<Settings> allSettings = daoSettings.GetAll();
int BackgroundColor = userSettings.BackgroundColor; // any of the columns here
userSettings.BackgroundColor = 0x45DA8E;
daoSettings.Save(userSettings);
Other ORMs exist, NHibernate may be a bit overkill if this is a one-time only situation and if you never did this before. However, it has an automatic level-1 and level-2 cache to prevent any unnecessary roundtrips to the database. It is currently (allegedly?) the industry leading open source ORM solution.
Update: added simple code example and links to NH/Fluent