I have three projects (WCF projects, not clients), I have one database for all, now how will I use EF with this? should I make a fourth project which will have the db context and the entities and then add a reference to it in all three projects? or should I just have a separate context for each project and just add the tables i need for each project? some of the table are really used everywhere. so what's the best solution for this?
Another question: should I expose the EF db context in the separate project so other projects can access it? something like:
MySeparateProject myPr = new MySeparateProject();
using (var db = new myPr.DBContext())
{
// do stuff with entities
db.SaveChanges();
}
I think the cleanest thing to do is create a data access project (class library) that contains just your models and db context, and reference that from all of your other projects.
Some people will say that you should make one class library with just the models, and then have yet another that has the DbContext, and the have repository classes, and then.... I feel this is overkill for the majority of projects. Having the models and context in one place just makes it really easy to keep all the dependent projects consistently in sync when it comes to data access.
Here's a typical project structure for me:
Here, Squelch.Data contains all of my models and db contexts, Squelch.Core contains core business logic, and my two "applications" (Squelch.Portal ad CdrImport), and the various test cases, all reference these base class libraries.
I would create a separate data access project. It is good practice to separate your data layer out anyhow. Depending on the nature of the project and how you want to test it, you may want to take a look at something like the repository pattern (though there is debate about its value with EF).
http://msdn.microsoft.com/en-us/library/ff649690.aspx
Related
When working with EF (v4,5,6) I have always used Database-first (I was mistakenly under the impression this was the only way to generate Entities from existing tables, EDMX, etc). But today I tryed Code-first, and it can also generate the POCOs (in a different way, no EDMX, different connection string, less cr8p lying around, etc..!)
So far, the usage of EF for CRUD appears to be exactly the same, can anyone who has used both please confirm there is nothing different (in usage), or gotchas I should be aware of?
And a supplementary question is, can I generate both in the same project ? (Not that i want to, but existing proj has EDMX within a folder, can I create another folder and generate Code-First Entities (different set of tables only), so i end up with DBContext and DBContext2 ?
Yes, the usage is the same. If you check the generated code you'll see they use the same System.Data.Entity.DbSet properties and they both inherit from the same System.Data.Entity.DbContext class.
Yes, you can generate both in the same project, but does not makes much sense, because you have to maintain both of them if the DB changes.
We have multiple model projects using codefluent (M1 and M2).
Is it possible to have one model project (say M1) using type reference of another model project (M2) ?
I tried adding project reference or existing item in model but none of them worked.
The import feature doesn't seem to be the way to go either
Shall I consider having only one model project for my solution ?
Thanks for your answer,
I think you want to create a relationship between entities of both models.
If so, it's easier to have only one model. If you create multiple models because of their sizes, you may be interested in parts and surfaces to split it (blog post about surfaces).
If you want to have multiple models, I think it's possible to create relationships between entities (but I didn't test it). You need to create the entity in both model and play with the producer specific attribute enabled (cfps:enabled, cfom:enabled, etc.). Unless you really want to do complex things, I think you may stick to one model.
Is it a good practise to storage Models in this schema in solution?
Models folder, where I have POCO classes (or objects with EF Data Annotations) and main file MyDbContext.cs
ViewModels folder, where I storage all of ViewModels.
In ViewModels folder I have every single viewmodel class in separate XXX.cs file.
Should I do the same thing with Models folder and objects in this model? I mean, no one big file AccountModel.cs, but separate User.cs, ExternalUserProfiles.cs etc.
And at least question - when I have to use EF Fluent API with POCO pattern instead of Data Annotations EF?
Regards.
Is it a good practise to storage Models in this schema in solution?
Yes it is, when the project grows large you can go further and replace each folder with a separate assembly.
Should I do the same thing with Models folder and objects in this model?
I recommend this too, this way you will have a parallel hierarchy and a better organization. As for MyDBContext I usually move that to the data access assembly but you can keep it with the domain model if you want and move it only when the data access layer get huge.
when I have to use EF Fluent API with POCO pattern instead of Data Annotations EF?
You can use whatever you feel comfortable with. The only downside of using Data Annotations is that it is tightly coupled to the actual domain objects. Another things is that Fluent API is capable of doing things not achievable with Data Annotations and allows better separation of concerns.
You can even use both of them at the same time, just use the best tool for job.
I recently, out of ignorance and lack of time, merged the domain models (POCO entity classes) from several projects into one 'DataModel' project, because I didn't want to duplicate dedicated DbContexts over all the projects. It struck me as ideal that something generic might be done, like a DbContext extension, to which one can add DbSet instances from various client projects.
I have read mention of such things, normally in the same circles as authors that contend - and I agree wholeheartedly - that the repository functionality is fulfilled completey by the DbSet class.
Can anyone offer any advice for building a generic DbContext which can exist in one project, where other projects can all have their domain models (sets of domain entities) registered with the shared DbContext, where they are all allocated they own DbSet to act as their repository?
building a generic DbContext which can exist in one project, where other projects can all have their domain models (sets of domain entities) registered
Interesting idea, but I'm not sure what you would gain by that.
For one, you'd never be able to simply type db.Customer (or similar). It should always be genericdb.Set<Customer>(), not knowing whether genericdb knows about Customer at all. (It may not have been registered).
Then, how should this registering take place? There are two ways to let a context map a class to a database model:
Creating a DbSet property in a DbContext-derived class and rely on code-first default conventions concerning table and column names, pluralization, etc.
Providing mapping configuration.
The first option defeats the purpose of a generic context class, so you'd have to register the domain classes by supplying EntityTypeConfiguration<T>s for each class in the domain, also for classes that normally could do without. (This should be done in the context's constructor, by the way.)
A further implication would be that somewhere you'd need a component/service that knows which groups of classes belong together and is able to deliver a coherent list of configurations. So, in stead of having dedicated contexts as an organizing principle out of the box you'd have to create your own organizer.
But back to the start. Couldn't you create a DAL that contains a DbContext factory that supplies the contexts as they previously existed for your projects? You don't have to duplicate dedicated DbContext classes this way.
I have now decided to try out ASP.NET MVC 3.
My host provider, however, only supports MySQL and therefore I have to figure out how to use MVC 3 with MySQL.
I have also decided that I don't wanna do any SQL code if I can avoid it, and I would also like O/RM without too much effort. I understand that the Entity Framework will actually help me accomplish this to a large extent.
I have been trying to get into the various ways of using the EF, with the database first, model first and code first approaches supplied by the framework.
So far, I have not had much luck, and I find that the examples available all use very different approaches that confuses me a lot.
I might begin by asking for guidance on getting a few concepts right.
First of all, the Model (in MVC) is actually more like a ViewModel, that represents something (Users, Posts, etc.) in terms of Properties is more or less simple classes. I.e. the model is where the data from the database gets mapped to an object (the O/RM). Am I right?
A repository is a wrapper that encapsulates a specific way of retrieving data for the models. For instance, a DatabaseRepository or a FakeTestRepository.
Should I have a single repository in my MVC project, or a repository per database table, such that I have a UsersRepository and PostsRepository?
Should the repository be a model for itself, not a model at all, or tied to individual models (so that UsersRepository is part of the UsersModel)?
I have tried to use the EF's model first approach, and for a simple test I just have created an empty model and added the entities "Author" and "Guide" that are related by a one-to-many relation.
When I then, in Visual Studio 2010, "Generate database from model", I get the corresponding sql code. I want this database to be created in MySQL. How can I accomplish that?
Are there some code examples for MVC 3 with MySQL and O/RM where the creation of a small site is demonstrated?
Thanks.
Concerning EF Model First approach: take a look at this Tips & Tricks article. We have described this common situation in it (it is Oracle-specific, but dotConnect for MySQL contains the "Devart SSDLToMySQL.tt" template).
As for the rest of the questions - there is no definite answer. Choose the approach that suits you better.
In my point of view, you should try the code first. And as you said that your host only provides MySQL you can also use MySQL database as a database I personally use MySQL. Concepts are the same but logic is different you have to code it a different way. But from my point of view, you can use MySQL as a database service.