How to Migrate from Plain Entities to Self-Tracking Entities? [closed] - c#

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm working in a project that uses .NET Entity Framework 4 with EntityObjects. Since we have found that we need to evolve into self-tracking entities for the remaining modules that haven't been implemented, I want to ask this:
1) Can we delete the existent plain entities and regenerate self-tracking entities from the database without modifying our currently written code using them?
2) If the answer of 1) is 'yes', is that easily done? How would you proceed to migrate from the first scheme to the second?

Change the namespces of your existing POCO classes to the one you expect EF will generate and so that your references will be updated.Then delete old POCO classes and generate EF classesThen compile your solution

By plain entities i presume you mean POCO's. You probably need to delete the POCO classes u wrote or generated and set the build action of the edmx file to EntityDeploy.
Hope this helps.

You just have to remove any old T4 you may have used (if you used POCO T4), and add new self tracking POCO T4 from your model.
It should be enough to work.

Related

The right ASP.NET boilerplate best practice [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I just found about the ASP.NET boilerplate framework for ASP.NET Core applications. The boilerplate is cool, it has all the necessary structure we need in order to create a SOLID proof web application.
My question is that, as per the site I have to create entity models in .Core project, and Dto's in Application project but as I can see these Question, and Answers are different entities but they kept both of them in the same folder and same namespace.
It does not look like a good practice, can anyone tell me is it wrong to keep these related entities in the same namespace/folder or it's ok to do so?
You can locate entities/services into any namespace. This is not related to the framework actually.
Question/Answer application is very simple project where there are just 2 entities. I thought that Question is aggregate root and answer is a child entity (they are a single aggregate together). This is why I put them into same namespace.
I suggest to follow "namespace per aggregate" principle, but "namespace per entity" is also fine.
BTW, #Dongdone, AspNet Boilerplate is completely open source & free. We have a another product, AspNet Zero (https://aspnetzero.com) that is commerical and developed on top of the ABP framework. But that does not make the ABP framework a paid tool. It's absolutely open source & free.

Nhibernate.AspNet.Identity Create the necessary tables [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am trying to use this gigantic bloated monster of a library, Identity, but I don't want to use entity framework. So I got NHibernate.AspNet.Identity!
I think I'm almost athe point of getting it to work but I can't seem to figure out how to generate the schema for the DB.
I thought it would automatically populate the DB with tables on first run. I was wrong...
Does anyone know where I can generate/find the schema for the database? Thanks!
Have you tried to use SchemaExport or SchemaUpdate (supports migration) classes from NHibernate.Tool.hbm2ddl? You may find usage example at What is schemaExport in Fluent NHibernate? and Fluent NHibernate - Create database schema only if not existing
In a nutshell the code for FluentNHibernate looks something like (and is similar for XML-based configuartion)
Fluently.Configure()
.Database(/* configure database */)
.Mappings(/* mappings */)
.ExposeConfiguration(cfg => { new SchemaExport(cfg).Create(false, true); });

How to persist views for ADO.NET EDM when database is recreated [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am working on a project that started with code-first POCO objects representing database structure. For development purposes we use drop and create when database is changed.
There is a new requirement for providing support for OData queryable endpoints. So I created new ADO.NET Entity Data model (generated from existing database).
I would like to use EDM only for retrieving data from database views.
But as far as I understand there is no way how to specify them "in code" so they would be persisted in the EDM. And if I create a view in the database, regenerate EDM and then change the code-first structure, the DB is regenerated and view is gone.
This is a problem only for development phase but a big one.
Only solution to this problem I can think of is to keep a SQL definition of all views and execute them when Entity Framework is creating the database.
Is there a better way?
Code first approach does not support creating Views. So you have to look for other options. I would suggest creating migrations (auto upgrade works in most cases) and avoid using drop/create method. This would preserve Views and keep all the benefits of code first.

How Code First used with Entity Framework 4.1? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How Code First used with Entity Framework 4.1 ?I want to know how Database is manged and Model is used in Code First Approach.Thanks
Code-First Development enables a pretty sweet development workflow. It enables you to:
Develop without ever having to open a designer or define an XML
mapping file. Develop without ever having to open a designer or
define an XML mapping file.
Define your model objects by simply writing “plain old classes” with no base classes required.
Use a “convention over configuration” approach that enables database persistence without explicitly configuring anything.
Optionally override the convention-based persistence and use a fluent code API to fully customize the persistence mapping.
Its a general question and lot of help is available on the internet.Following link will be helpful to implement Code First Approach.
http://msdn.microsoft.com/en-us/magazine/hh126815.aspx
http://weblogs.asp.net/scottgu/code-first-development-with-entity-framework-4
With EF 4.1 the database is not managed. You can have it generate the database on your initial creation but EF 4.1 does not use Migrations. You could create a custom solution to manage the database piece but it may prove to be a pain and dangerous in a prod environment.
Not sure how familiar you are with EF but if you have not used it I would recommend as others have reading a tutorial or 3. Also, if possible I would use the newest version of EF that you can as a great deal has been updated since 4.1.
Here is a tutorial.
http://blogs.msdn.com/b/adonet/archive/2011/09/28/ef-4-2-code-first-walkthrough.aspx

Enterprise Library or Entity Framework [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
which one is more useful for a project with a huge database
useful means :
Insert and delete and update fast
select a lot of rows fast
update database structure easier
programmer friendly
, .....
we have considered that database implement is in the best situation of indexing and ....
thanks
From http://forums.asp.net/t/1647988.aspx:
DAAB is the Data Access Block provided by Ent. Lib.
They are completely different animals. The DAAB is a data access library (wrappers around ADO.NET), whereas the Entity Framework is an Object Relatonal Mapper. They don't do the same thing. If you want to use a data access library, Microsoft would recomend the Entity Framework. If you want to use an ORM. they would recomment EF.
Other similar question on here:
Entity framework vs enterprise library
General Questions about Entity Framework vs. Enterprise Library & a few others

Categories