I am in process of making the c# .NET standard library which eventually should be published on nuget.
Since library encapsulates communication with database, I wanted to use EF core (Code First) to setup database model.
Users of the library should be able to generate database model for arbitrary database(i.e. user should specify connection string) from code, which is contained in library, i.e. migrations should be located in the library.
My concern is: Is this even supported scenario by EF core.
So far browsing the the internet resulted with no info about this scenario.
My questions are:
Is this scenario somehow supported in EF core.
If not then what are the ways to implement library which contains database model(either in the form of SQL script or migration code), user of the library should be able to specify connection string and generate database model.
Related
I'm working on a ASP.NET Core Razor pages project that includes IdentityServer and IdentityFramework with various customisations to the identity model -- all quite standard stuff.
What's not standard, though, is that someone has deicded to not use EntityFramework migrations but use DbUp instead.
I can see that changes to the C# model correspond to SQL files -- in the same way that they would correspond to EF migrations.
The mystery is how the DbUp SQL files were produced.
The filename are of the format M<timestamp>_<name>.sql -- where has the initial M come from?
None of the projects has the dbup-add-migration package installed (only dbup-core and dbup-sqlserver).
So: if, say, I edit a model class then what do I do to make the corresponding MyyyyMMdd_name.sql file?
At a conference yesterday, I learned about the importance of putting your database in source control. They showed us how to make a new Database project and import the database.
What I was wondering about is how I would change an existing project running on Entity Framework to utilize the database project's power?
Schema updates have always been done by using Entity Framework Migrations. I get that the Database project will be able to deploy database updates for me and save those update scripts to source control, but I would like to keep Entity Framework for querying my data (if that makes any sense at all).
Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project in Visual Studio ? How do you go about this?
I've tried searching for similar questions and using Google to find if anyone else is having the same problem, but no dice so far.
I should also state that I am considering using this in databases that also have stored procedures in them. These are not controlled through Entity Framework at all, and therefore are not in source control yet.
Thank you for your time.
What I was wondering about is how I would change an existing project
running on Entity Framework to utilize the database project's power?
Answer: I suggest you to see this course from Plural Sight : https://www.pluralsight.com/courses/code-first-entity-framework-legacy-databases
Is it possible (or even: recommended) to use Entity Framework to access the database but manage the database using a Database project
in Visual Studio ? How do you go about this?
Answer: Yes, it's possible and recommended. Your data project becomes the source of truth about the structure of your database. This is very powerful to keep control of all the changes and state of your database in one place (Visual Studio). The course from the first answer will teach you how.
I should also state that I am considering using this in databases that
also have stored procedures in them. These are not controlled through
Entity Framework at all, and therefore are not in source control yet.
Answer: I don't see any problem using stored procedures. The tool from the Plural Sight course will create the procedure in your source control and the reverse engineering will create a class/method for easy use of the proc.
I just came across the below alternative, which I didn't test though:
Generate Entity Framework Core classes from a SQL Server database project - .dacpac file
I believe this should be something to be considered
I developed an application like that, having 2 projects: application itself and the SSDT project for the database. The database changes were deployed via change scripts, and EF migrations were disabled in the application.
Everything worked fine, although it did bring a bit of an overhead. For example, it was a bit of a hassle to introduce major database updates / refactorings into the EF layer. For some reason, I was unable to reverse engineer database changes directly into the app, so I had to do it half-manually: creating new project, generate EF context for the entire database, and then copying new / changed files into the main application.
(Then again, it was almost 5 years ago. With luck, EF scaffolding has improved since then.)
I'm reading through Derby documentation and following all the instructions. I've successfully installed it (extracted it to my Linux machine and set the DERBY_HOME path). I have a complete REST API project with Angular 7 front-end and Dropwizard backend. I hard coded some data in the backend, and created all the HTTP API methods I need (GET, POST, PATCH, DELETE).
The application is fully functional, but now I need to implement the Embedded version of Derby into it. I have 0 experience with such databases, and because Dropwizard gave me enough trouble already, I cannot figure out how to get started.
Do I create a new class and get started there, how to create those SQL files and how to store data? I can't find a concrete answer to similar questions, if there are detailed explanations and examples already out there, please feel free to provide me with the resources. I know this is a noob question, but I just barely learned how HTTP works (the basics) and managed to completely create a functional REST using Angular and Dropwizard.
Consider the embedded database like a full-fledged database, that instead of being in a different environment, and maybe requiring a network connection, is packed along with your application and run in the same JVM. The same mechanisms applies between the two.
The embedded Derby Driver is located inside the derby.jar file, so it is required to have it in the classpath of your application. It should be located under %DERBY_INSTALL%\lib\, where %DERBY_INSTALL% is the installation directory. You can see by the image where it is contained.
From Oracle
Any JDBC 4.0 drivers that are found in your class path are
automatically loaded. (However, you must manually load any drivers
prior to JDBC 4.0 with the method Class.forName.)
What that means is that if the Derby driver is a JDBC 4.0 driver, you don't have to do anything else besided getting a connection via DriverManager.
If it is not a JDBC 4.0 driver, you'll have to instantiate the Driver with
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
Appartently you'll need that piece of code above.
Now simply get a hold on a Connection object.
DriverManager.getConnection("jdbc:derby:dbName;create=true");
From there on, you can create Statement(s) as you like. Which means you can create tables, insert rows, update rows, delete rows, etc.
To gracefully shutdown the embedded Derby database, you need to use
DriverManager.getConnection("jdbc:derby:dbName;shutdown=true"); // see the same database name "dbName"
prior to quitting the main application. It is not mandatory, but recommended.
You can create a utility class to hold an EmbeddedDataSource (docs), which will provide connections around your application.
public final class EmbeddedDerby {
private static final DataSource DATA_SOURCE;
static {
// Initialize DATA_SOURCE with EmbeddedDataSource
}
...
public static Connection getConnection() {
return DATA_SOURCE.getConnection();
}
}
I'm currently working on a Grails project which has a static production database with a lot of data in it. I would like to test my application using the production data, but instead of having to clone the production database I'd like to setup a proxy database to the production database.
Essentially reads of the database would go all the way to production database while writes would stop at a proxy database (preferably an h2 database). If a row was updated that came from the production database the row would be saved to the proxy database and returned, instead of the production's row, on subsequent queries.
I'd like to do all of this as transparently to the application as possible. My currently line of thinking is that I'd need to fork the Hibernate GORM implementation and make it support this use case. Has this been done before? Is there a better way?
Forking the Hibernate GORM implementation may not be a good idea. You will be stuck in your version and will have to, somehow, make this up to date with the original plugin (eg. bug fix, new implementations).
Maybe a custom TestMixin that allows you to override all registered domain classes, with new implementations of save(), get(), find() and etc can be an option. You can work with the metaClass to override this static methods and this will be triggered only on tests with the annotated mixin.
With this you can use multiple datasources in the test environment to determine which will be used.
Currently I have a working Silverlight application that uses .Net RIA Services.
It's structure:
Client-side
Application.Client.UI.dll (Xamls and
basic UI stuff)
Application.Client.BL.dll (Contains the Link to RIA and most of the business logic)
Server-side
Application.Server.Data.dll (Server-side dll that holds the Entity-model and it's generated domain service)
Application.Server.Web.dll (Only the ASP.net hosting container, which references the
Application.Server.Data.dll)
I placed most of the business logic on the client side (Application.Client.BL.dll) for better user-experience (fast reactions) and to free up server resources. My challenge is now to re-use this client-side dll including it's RIA data access capabilities, in a server-side windows service. I'm wondering, is that possible at all? Is the Application.Client.BL.dll still able to consume the existing RIA service, or does that dll require the Silverlight runtime to identify/locate it's service target, and therefore will not work anywhere else.
Curious for your answers
You really shouldn't put any business logic on the client, the guys in security and / or architecture will hate you for it ;-). Furthermore you can't use Silverlight assemblies in ASP.Net or Desktop projects and vice versa. If memory serves correctly, Silverlight uses an entirely different CLR altogether.
I encountered similar needs when working with compact framework assemblies I also wanted to compile for the full framework. I'll describe how I would work around this scenario.
If there exist any issues referencing the Silverlight assembly, consider building two projects as follows:
Project #1 would be your Silverlight library, and should contain all the source files you want to use on the client.
Project #2 would be your Windows Service. Instead of including source files directly, use the "Add Existing Item", find the original source file in project #1, then (and this is the magic), drop down the Add button to choose, instead, choose "Add as Link".
By including the source file as a link, you retain the ability to maintain your source code in one location, but add the ability to compile your code for multiple frameworks. As long as the code relies on assemblies available in both the Silverlight framework and the full .NET framework, then you're money.
Now, regardless of whether you choose a multi-project approach, know that domain context classes have additional constructors that allow you to specify contextual information, such as the URL, for the corresponding domain service. I use the following code in one application to construct a domain context for a domain service that provides personnel data:
var context = new PersonnelDomainContext(
new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))
In this case, the URL looks something like:
http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc
Of course, when writing a Windows Service, nothing is stopping you from referencing the server-side domain service (not context) assembly directly. With the domain service in hand, you can instantiate a service instance without all the additional configuration and without the additional network XML payload. There are trade-offs to this approach, such as forfeiting centralized configuration management (such as connection strings), but depending on your circumstances, you may find the trade-offs to be worth it.
Happy coding!
Have you considered using fork-reuse? Take a look at:
http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html