Exclude DbContext from migrations to avoid Context-Parameter - ef-code-first

I'm using ASP.NET EF Core with MySQL (Pomelo.EntityFrameworkCore.MySql driver). Cause such a context need some lines of specific configuration which the default DbContext with MSSQL doesn't have, I created a MySqlContext:
public class MySqlContext : DbContext {
string connectionString;
// ...
}
So all my DbContexts are inherited from those class:
public class MyDbContext: MySqlContext {
public DbSet<MyModel> MyModels{ get; set; }
// ...
}
In my project I have currently one context (DbContext) which contains DbSets. And the MySqlContext, which isn't a real context like this because it has no DbSets and only acts as a wrapper for the MySQL configuration so that I can better re-use them.
But it seems that the migrations will see them as two different contexts because when I add a migration using command Add-Migration Test I got the error
More than one DbContext was found. Specify which one to use. Use the '-Context' parameter for PowerShell commands and the '--context' parameter for dotnet commands.
So on every migration I have to add -Context MyContext to the command. I would like to avoid this, because as I said the second MySqlContext is not a real context which holds models and migrations. Is there a way to tell the migration tool this? I need something like the [NotMapped] attribute for EF models, which tells EF: Dont store this property to the database. Like this I need to tell EF: Ignore the MySqlContext class cause they need no migrations.

Make base class abstract:
public abstract class MySqlContext : DbContext {
string connectionString;
// ...
}

The Use-DbContext MyContext command will set MyContext as the default context to use for your PowerShell session. This is another way to avoid having to specify -Context every time.

Related

How can I execute a method by accessing autowired object in spring MVC from separate standalone java application

Let's we have a class in webapp.war (spring MVC 4.2.2.RELEASE)
public class SomeClass{
#Autowired
private MyInterface implObject;
public void method1(){
implObject.doSomething();
// statements ...
}
}
and another class in standalone.jar
public class MainClass{
public static void main(String[] args){
// want to create object of SomeClass
// or execute doSomething() ...
}
}
Note: application will be deployed in clustered environment, standalone.jar will be executed by shell script (it will be registered in crontab).
I want to schedule some job (fetch records and send to weblogic queue JMS ...), using Unix crontab. and don't want to repeat DB operation separately (in standalone.jar).
Please also suggest if I can make standalone.jar small in size.
Quartz or similar implementation is not expected in my case.
Thank you.
I solved this problem by extracting necessary part of webapp.war, into app.jar.
Scheduling and batch configured using crontab.
Used maven build tool i.e maven-shade.
Any required configuration left to spring.

UnitOfWork + Repository patterns and Entity Framework impersonation

I have used UnitOfWork and Repository patterns in my application with EF.
Actually my design provides that the UnitOfWork would create the ObjectContext class and inject inside the Repository concrete class. For example:
UnitOfWork.cs (initialization)
public DefaultUnitOfWork() {
if (_context == null) {
_context = new MyDataContext(ConfigSingleton.GetInstance().ConnectionString);
}
}
UnitOfWork.cs (getting a repository instance)
public CustomerRepository Customers {
get {
if (_customers == null) {
_customers = new CustomerRepository(_context);
}
return _customers;
}
}
This way the Repository classes have an already defined ObjectContext class and they can use it's methods to retrieve and update data.
This works nice.
Now I need to execute my queries impersonating the Application Pool Identity so I have decided to wrap the code in the constructor of the UnitOfWork within the impersonation.
Unfortunately this does not work because the ObjectContext is then passed to the Repository constructor and used later when a client of the repository calls, for example, FindAll().
I have experienced that the real connection to the database is made right before doing the query by Entity Framework and not exactly when I am creating the ObjectContext itself.
How can I solve this problem?
You could use one or more ObjectContext Factories (to create ObjectContexts), using different creation criteria, such as Connection String, for example. Your UnitOfWork could leverage a factory to get its Context and so could the Repository, but I think you've missed the point of UnitOfWork if it is leveraging a different ObjectContext than your Repository.
A UnitOfWork should consist of one or more operations that should be completed together, which could easily leverage multiple repositories. If the repositories have their own ObjectContexts separate from the UnitOfWork, I don't see how committing the UnitOfWork will achieve it's purpose.
I think either I've misinterpreted your question completely or you've left out some pertinent details. Good Luck!

Code first: Where's the connection string & the Database?

I'm testing how code first works. Here's how I defined the Context
public class EfDbContext: Context
{
public DbSet<Client> Clients { get; set; }
}
I didn't create any data base, but I was able to do all the CRUD operations.
Now I don't see the connection string in my web.config. I don't see either the Database. I've checked the App_Data Directory and also the Sql Server Express. I don't see any trace of the Database created.
Yet, everything is perfectly.
EF code-first will use a connection string that has the same name as your DB context - so you could define it like this:
<connectionString>
<add name="EfDbContext"
connectionString="server=YourServer;database=YourChoice;Integrated Security=SSPI;" />
</connectionString>
The database won't be created by default, until you actually do something, e.g. it should show up as soon as you make a call to EfDbContext.SaveChanges() for the first time.
It will be called the same as your DB context (YourNamespace.EfDbContext) if you haven't defined your own, custom connection string, and it should show up in your default local SQL instance.
See from the ADO.NET EF 4.1 Code First Walkthrough:
Where’s My Data?
DbContext by convention created a database for you on
localhost\SQLEXPRESS. The database is named after the fully qualified
name of your derived context, in our case that is
“CodeFirstSample.ProductContext”. We’ll look at ways to change this
later in the walkthrough.

How to use Membership provider with EF Code First?

I have models based on EF Code First and I want to use them with the default MembershipProvider, but I don't know how to write the model correctly, so it won't erase all my data on recreating the tables when there were changes made to the model.
Have a look at this project
http://codefirstmembership.codeplex.com/
It has entity classes for users and roles, as well as a roleprovider and membershipprovider implementation. If you include the users and roles in your datacontext class the tables will be created in your database.
Your question has two parts.
How to use asp.net membership API with EF code first?
How to preserve existing data when model changes?
as for How to preserve existing data when model changes, as far as with EF 4.0/ asp.net mvc 3, database migrations are not yet supported. You will have to move to asp.net mvc 4.0/ EF 4.3 where database migrations are supported or use similar alternatives , but its still beta release.
asp.net mvc 4.0 database migration in scott gu's blog
Now coming to the point on how to use asp.net membership provider with EF code first. There are couple of challenges :
We cannot/should not do an join with asp.net membership provider tables. Its not recommended, so my suggestion will be to create a "adapter class" for asp.net membership provider classes. For ex :
public class UserAdapter
{
// all user related attributes. Not stored in membership schema, but your schema
public string UserProxyName;
// some attributes stored in membership schema
[NotMapped]
public string Email {
get
{
Membership.GetUser(UserProxyName).Email;
}
}
// some attributes stored in membership schema and not in your schema
[NotMapped]
public string[] UserRoles
{
get
{
return Roles.GetRolesForUser(UserProxyName);
}
}
}
Now for updating information , you may write some functions in Model itself, however i would suggest create a UserRepository with repository design pattern to handle user CRUD operations.
Second challenge is how to create the database on first run. As seeding becomes an issue, if you want to seed user information then seperately running aspnet_regsql is not efficient as membership schema is expected before the seeding happens. I came across this nice article , with some fine tuning it worked for me :
asp.net membership and EF
Currently (EF 4.1 CTP) EF Code First doesn't have that option. It always drops a table if you made changes to model.
Update:
EF 4.1 RTM allows you to create a custom database initializer and specify creation of db objects and data seeding.
If you are using SQL Server, then check this :
http://www.paragm.com/ef-v4-1-code-first-and-asp-net-membership-service/
There is also my library which basically allows you to define how almost everything should be configured including: key type, where the your context object is, and where your user/role entities are located. Extendable using abstract base classes or interfaces. Also works quite well out of the box with repository pattern / unit of work / IoC Containers.
Source: https://github.com/holyprin/holyprin.web.security
NuGet: https://nuget.org/packages/Holyprin.Web.Security
In my DbContext.cs file I have a Seed function where I call the ApplicationServices.InstallServices() to install the ASP.NET Membership to my database. Now everytime my initializer drop the database it recreates ASP.NET Membership schema again.
public class PanelInitializer : DropCreateDatabaseAlways<PanelContext>
{
protected override void Seed(PanelContext context)
{
//Install ASP.NET Membership
ApplicationServices.InstallServices(SqlFeatures.Membership | SqlFeatures.RoleManager);
new List<Panel>
{
The ApplicationServices class
using System.Configuration;
using System.Data.SqlClient;
using System.Web.Management;
namespace Lansw.Panels.DataAccess.Contexts
{
public class ApplicationServices
{
readonly static string DefaultConnectionString = ConfigurationManager.AppSettings["DefaultConnectionString"];
readonly static string ConnectionString = ConfigurationManager.ConnectionStrings[DefaultConnectionString].ConnectionString;
readonly static SqlConnectionStringBuilder MyBuilder = new SqlConnectionStringBuilder(ConnectionString);
public static void InstallServices(SqlFeatures sqlFeatures)
{
SqlServices.Install(MyBuilder.InitialCatalog, sqlFeatures, ConnectionString);
}
public static void UninstallServices(SqlFeatures sqlFeatures)
{
SqlServices.Uninstall(MyBuilder.InitialCatalog, sqlFeatures, ConnectionString);
}
}
}
Thanks to #ImarSpaanjaars http://imar.spaanjaars.com/563/using-entity-framework-code-first-and-aspnet-membership-together.

Registry equivalent in Unity

Is there any equivalent to the Registry class from StructureMap in Unity?
I like to think about a layer/component/library to configure it self - thus populating the container. So the "parent" layer will just need to know about the Registration class.
No, there isn't. In our current project we have manually mimic'd the concept of a Registry although our implementation isn't nearly as powerful as a StructureMap Registry.
If all you are wanting is modularized container configuration, what you could do is create a marker interface (maybe IRegistry) and then have your application scan for IRegistry classes. With Unity, you can resolve classes that haven't been registered into Unity yet, so you could simply resolve each IRegistry implementation as you find it. The registry classes could take the container as a constructor parameter and then each class could configure the container as needed for that layer/component/library.
public interface IRegistry
{
void Configure();
}
public class ServicesRegistry : IRegistry
{
public ServicesRegistry(IUnityContainer container)
{
_container = container;
}
public sub Configure()
{
// Configure container for layer
}
}
Now in your app startup somewhere you could have an application bootstrapper that either knows about all your registries or knows how to scan for them.
You can try UnityConfiguration which is a convention based configuration API for the Unity IoC container, heavily influenced by StructureMap
https://github.com/thedersen/UnityConfiguration

Resources