Maybe its just me but I am not a big fan of using the DBContext Generator as it adds overhead to development.
I like using the Entity Framework DBContext API but want to get rid of the hand coding of POCO classes. I am wondering if there are any T4 templates out there that can connect to MySQL or SqlServer and Generate the POCO classes from the database. Using the DBContext Generator template you have to update your database, update your model, re-run the T-4 templates to generate POCO classes. I would like to cut the steps down so that I don't have to generate and maintain a model.
Are there any T4 alternatives to the DBContext Generator that create the POCO classes and don't require an edmx model file?
There was alternative in EF Power Tools CTP1 but that is far away from power of DbContext Generator. Moreover those generations features from power tools were only for initial class generation. It didn't include any possibility for updates once you do any changes in the database.
You have probably missed point of DbContext generator. This generator creates classes from mapping defined in EDMX. It is very easy to use - it has just single additional step with updating model. If you have model and T4 template in the same project you will even not need to regenerate classes yourselves - it will happen automatically once you save changes in EDMX (so it will be only two steps).
What you are looking for would still have two steps (updating model and running the template) so the difference is "none". What you are looking for would not provide any significant boost to your process. It will only make all mapping more complex because you will have to hardcode it into template - that is also reason why such template probably doesn't exist.
Related
I'm using EF Core and have generated the database with migration (code first). In the meantime I have created a View in DB directly and would like to reverse engineer this views in my dbcontext file. I know I can follow this link to get the view but I don't know if this can mess up my existing dbContext class or not.
Is there a recommendation that you only need to use migrations or reverse engineering, or can you mix them depending on the use case you have.
I've always used one or the other, but having the reverse engineering feature in such a case would be great, but I'm not sure if this is a good idea.
Thanks
I would recommend you to not mix these two things. With reverse engineering, you will get a generated DB context class file, but with the code first approach, you are manually writing the context file.
Why do you want to use reverse engineering? If you want to create the entity classes for the views from the DB, you can use it, but in my opinion this is not so comfortable (you should only keep the changes that are related to the views and drop everything else).
I've worked for some time with entity framework in a database first approach with all the fancy code generators from VS. But I have two problems with this :
1) As powerfull as it is, I am just sick of .edmx and generated code plus I want to keep the hand on my models objects. I don't want my models to be the exact reflect of my database, I just want them as I need them.
2) I no longer have access to code generation and .edmx, since I'm now working on VS Express 2013
The code first approach is not an option, since I work on an existing DB.
I have given a look to Massive and such, and I do love it, but it also reminded me how wonderful it is when many-to-many relationships are automatically managed...
So is it a way to "manually" wire objects to tables, like in Java's hibernate ?
I am looking for an NHiberate mapping generator that can generate mapping by code rather than .xml or Fluent NHibernate.
I tried NHibernate Mapping Generator, but it has no validation. Thus, the existing mapping files might not 100% correct.
Devart Entity developer doesn't support this currently.
Any recommendations?
You could try nHibernate Designer from MindScape.
Well since you are asking for a suggestion, I can say by experience don't try to use a code generator. Such kind of approach fails when the project grow, you suddenly need to add some modifications and re-generating the entities would be a pain and so on. Try to read about ConventionalMapping. It is basically a strategy in building the mapping on the fly based on some conventions generally exists in a database table vs classes naming. I did this in past and with a little effort you will be able to concentrate just on the classes and completely forgot the mapping.
Background:
I started to create logical database model for ASP.NET MVC web site. I used visual designer for Entity framework that ships with VS because I have used it before.
But now I already have 33 classes and I'm not finished (including quite some inheritance and a lot of associations). I'm afraid that it would be too complicated and time consuming for me to manually set all the table mappings and than generate database tables. I've no experience with it - I've done it the other way: classes from database tables and it took me a lot of time to get it work in a smaller project.
Question:
How can I easily and quickly create database tables for logical model (class diagram) in .NET / VS ? It would be great if it was possible automatically. I have never worked with LinqToSQL visual designer and it seems to be no reference on the web on how to create database tables from LinqToSQL classes. Is it possible at all ? If not is there any way to create database tables with Entity framework automatically - without having to specify table mappings ?
And one side question: if I used LinqToSQL classes are that going to commit changes to database every time I change properties ? Or is some caching taking place there ?
Entity framework has a concept called "Model First", which generates the database model from you model, hence the name.
You can read about that here: http://msdn.microsoft.com/en-us/data/ff830362
However, my personal favourite when it comes to Object Relational Mappers is NHibernate with the addition Fluent NHibernate. They have a concept where you work with your domain model rather than you data model and you use conventions to control your mappings. It's pretty neat. You can get started with some pretty good examples by looking at this code here: https://github.com/sharparchitecture/Northwind/tree/master/app
Linq2Sql is too limited for the case you are talking about. And it has no capability to generate data models from code. In fact, Linq2Sql works the other way around - it generates a set of classes from your data model, much like Entity Framework also can do.
Neither Linq 2 SQL or Entity Framework commit anything until you explicitly choose to do so. They both have a notion of a object context which keeps track of all changes made. When you call "Save", they transform those changes into SQL which is then executed in the database.
Like MikeEast, I've had a very good experience with Fluent NHibernate.
On my project, I use the Automapping feature, which allows me to change my data model almost at will, and the database schema automagically gets updated.
No SQL, no worrying about foreign keys, etc, etc, etc - I love it!
Fluent NHibernate Automapping
Finally I have sticked with Entity framework - tables generating is really plainless once I learnt how to deal with database connections...
I've begun experimenting with LINQ to SQL and what I am doing is basically creating classes with LINQ mapping decorators - thereby choosing which parts of the db table schema I want to incorporate into my classes.
A simple example:
private DateTime? _LocalCopyTimestamp = (DateTime)SqlDateTime.MinValue;
[Column(Name = "recaLocalCopyTimestamp", Storage = "_LocalCopyTimestamp", CanBeNull = true)]
public DateTime? LocalCopyTimestamp
{
get
{
return this._LocalCopyTimestamp;
}
set
{
this._LocalCopyTimestamp = value;
}
}
I am not using and am not willing to resort to modeling tools due to project contraints (the way schema changes are handled and because there is an existing database schema and it is a bit too organic and non-strict)
Is there a way to have this flexibility with the Entity Framework without having to include schema information files and/or lots of distinct code files?
Could I then also create classes that "use" more than one underlying table?
Can anyone point me to documentation regarding this?
The feature you are requesting (write C# classes and generate your model from those) is termed by the Entity Framework team "Model First." It does not exist in the current, shipping version of the Entity Framework, but is a planned feature for the next version. If you watch the Entity Framework talks from PDC, you can see demonstrations of this new feature. With the current version, you do not have to write "many" mapping files, but you do need one (the EDMX file), and it must be XML.
Yes, you can create entity classes which use more than one underlying table. This is called "Entity splitting." Step-by-step instructions at the link. In general, you will find that the Entity Framework supports many more complicated mapping scenarios than LINQ to SQL.
I'm afraid that I have to completely disagree with Marc regarding writing EDMX without use of the designer. Writing EDMX without using the designer is not only possible, but for projects exceeding a certain side, it is all but inevitable. A few points on this:
For most of the early history (pre-RTM; "ObjectSpaces") of the Entity Framework, writing the XML files manually was the only way to use the tool. The designer is a recent feature, and is considerably less stable than the Entity Framework itself.
There are certain Entity Framework features, such as complex types, which are not supported in the designer at all.
Certain mapping scenarios, such as not mapping individual columns, or mapping tables without a foreign key relationship, which may be necessary for legacy databases, are not supported in the designer.
As I mentioned in (1) the designer is quite a bit buggier than the Entity Framework itself. So on larger projects you will probably end up having to clean up after the designer's mistakes.
Entity Framework uses the EDM to model data; this is a set of 3 complex schema files (storage, conceptual, mapping), most commonly stored as resources in the project (via the designer which uses a single EDMX file to generate all 3 schema files).
It doesn't support attributed classes for this information. The only sensible way to write EDM is via the designer (essentially, a modelling tool which you dislike).
Re classes the "use" more than one underlying table; yes, a single Entity Framework entity at the conceptual layer (i.e. classes) can span multiple storage tables. This is especially useful for some inheritance examples, but can (IIRC) be used by flat models too. You do this via the "mappings" between the storage and conceptual layers (most commonly; on the tab in the designer).