I have used code first method before, but somehow I could not think of a way in making my Code First works. I have developed the POCO and DbContext. But now I am stuck on how to get the database created and subsequently used in my application. Do I need to add something in the project?
Currently default provider System.Data.SQLite doesn't support database creation. To have ability to create database programatically from your POCO model objects you need to consider to use for example Devart's SQLite provide. But this is paid solution.
For more information see answer for the following stack overflow question.
Related
I'm a very beginner in .NET and now I'm developing a little project (web API) using NancyFX framework. In my project, I need to use SQL database for some very basic tasks like storing registered users' details or getting some user information. I'd like to know what is the most popular, convenient and modern way of using SQL in .NET for beginners? I mean, should I use LINQ or just pure SQLClient functionality or are there any good libraries for working with SQL on .NET? I've tried to implement LINQ to SQL pattern but ended up with huge chunks of unused auto generated code and even bigger mess in my head...
For a framework to communicate with you're database I would recommend using Entity framework, its very convenient and easy and has the Code first approach which you should read about.
More over i suggest you follow the repository pattern,
https://msdn.microsoft.com/en-us/library/ff649690.aspx
This basically means - each object you save in the db, will have a repository which will contain all the object of its kind and that will be you're entry point to reading/inserting/updatibg/and deleting rows from the db, while abstracting away all details of implementation - in our case I recommend entity framework as I mentioned before.
Good luck
Sorry if this is a totally noob question but I just can't seem to find a starting point on this.
From what I've gathered so far SSDT was developed with the idea that it would be used in a different project that that of the main app for database related coding. I figured that instead of complaining about how much I like the old version back, I'd try things their way and see how well it goes but I can't seem to get a handle on where to begin over here.
Basically I want to use a code first approach and create a database from a designer. If I'm going to create a new project to handle the entity framework, what type of project should it be? a C# class library, WPF.. something else?
I'm not sure if it's of any relavance but the app I'm working on is a WPF app and the database is MySQL.
If you want to use a code-first approach, then that means that the database will be generated by the code. Thus, you will not have a separate database-project, since that would mean that your database is kept in two places. Therefore, your options are:
Use code-first. This usually means a class library (although asp.net mvc usually has the context with entities in the asp.net mvc project, let's call that an exception to the rule). The class library will contain classes with which your database will be generated.
Use a database project, an SSDT project. Your database will be defined here, and when you deploy this project the database will be generated/updated.
Note: AFAIK an SSDT project is specific to SQL Server, so since you are using a MySql database it is not an option.
I've been looking into using and MVC C# frontend to a Caché database backend. After looking around for a while i haven't been able to find an effective way of connecting the two together (via .edmx model generation). I know I'll need a database driver for Visual Studio 2012 to do this but i don't know where to find it.
I've been developing a few apps using MVC technology and want to keep following suit instead of resorting to using their .csp based technology.
Hopefully somebody can help with this.
Take a look at the Cache Managed Provider for .NET documentation:
http://docs.intersystems.com/cache20121/csp/docbook/DocBook.UI.Page.cls?KEY=GBMP
The Managed Provider functionality specifically allows you to access Cache data from within .NET programs. It's not going to be as nice as using, say, the .NET Entity Framework to do data access, plus you'll have to take InterSystems' code example with a grain of salt since they are pretty simplistic, but this should be what you need.
You can use an ORM framework like Entity Framework or NHibernate to get access to Intersystems Cache so the database can be separated nicely in the data layer. I managed to make NHibernate works with Intersystems Cache works. Have a look at here if you are interested.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
EF 4.1 Code-first vs Model/Database-first
i made some research, but answers did not satisfy me.
I started my own asp.net mvc application with entity framework, to work with database. I started by making a db, than i create model from that database. Well i know thats called "model-first". I know the second way, of doing it from school (code first). My lecturer told me today, that model-first method is rly outdated. Well is that true? Or maybe: does code-first have any advantage? Whats the real difference, which one is better, in your opinion?
Specifically with EF code first refers to the code and model first refers to the database.
which is better really depends on the project. If the db is treated as the core of the application, or you are using db specific features, than a model first approach makes sense.
If the domain model is treated as the core of the application, leaving the db to be just a form of persistent storage, than a code first approach is practical.
as a side note: this concept is usually referred to as model first (the domain/code) and db first (the db schema). with EF this is somewhat confusing as model refers to the db schema, not the domain model and code refers to the code.
DB first is not outdated at all. In fact, for many corporate projects that's the way to go.
If you are building something for yourself from scratch, code first will probably be a better approach.
Entity Framework provides: 1)Database first, 2)Model first and 3) Code first.
1 & 2 Creates the edmx file
Database first: Entity Data Model(edmx:StorageModels) is created from an existing database.
Model first: Conceptual Data Model(edmx:ConceptualModels) is created with designer and mappings specified. Database will be generated from this.
Code first: Create your .NET classes(no .edmx file). Database will be generated from this.
'Old school' would be using ADO.NET DataSet/DataTable.
Fastest data access is using DataReader and writing your own data access.
No framework will be faster than using a DataReader to populate your own POCOs.
I have a WCF application in C# .NET 4.0. I made all my entity classes and can query a sample from the WCF. The sample is just hard coded values.
Now I am ready to persist these in the database. I am lost on how to approach this though. I plan to create tables for each entity class I created, but what is the best way to add the persistent data layer to my existing WCF application. Is Entity Framework a good choice for this? Thanks for any help or suggestions.
What I suggest is to use entity framework code first. It prevents you from re-creating the model/database by hand. Just set it up so that your current entity classes are mapped to the entity framework and it will automatically create the database for you.
If you google entity framework code first, i'm sure u cant miss it.