Entity Framework VS Linq To SQL
-
I've always done Linq to SQL which I like. It's easy to setup and work with. I follow a typical n-Tier architecture: UI <--> BL <--> DAL <--> DB I've only set up Entity Framework once. When it generated the Data Context all the entities were in the same DAL project. This means that my UI, BL, and other projects in the solution all needed a reference to the DAL. This seems like a tight coupling. I was able, with a lot of work, to generate the entities into a separate project. Then, the other projects in the solution only needed to know about the new entities project, but again it was a lot of work to set up. So, how is EF typically used? What's the right way to set up the DC and entities? Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I've always done Linq to SQL which I like. It's easy to setup and work with. I follow a typical n-Tier architecture: UI <--> BL <--> DAL <--> DB I've only set up Entity Framework once. When it generated the Data Context all the entities were in the same DAL project. This means that my UI, BL, and other projects in the solution all needed a reference to the DAL. This seems like a tight coupling. I was able, with a lot of work, to generate the entities into a separate project. Then, the other projects in the solution only needed to know about the new entities project, but again it was a lot of work to set up. So, how is EF typically used? What's the right way to set up the DC and entities? Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Use the "Code First" approach, even if you're connecting to an existing database. That way, you can put your entities wherever you like, so long as the DAL project has a reference to them. If you're using an existing database, there's even a wizard to create the code first classes for you, which you can then move to another project as required: Entity Framework Code First to an Existing Database[^] The BL layer might be able to reuse the EF entity classes. But you'll probably find that you need to make changes to the layout, particularly when dealing with navigation properties. In that case, you'll want a parallel set of DTO classes, and something like AutoMapper[^] to map data between them. The UI layer will probably need its own parallel set of view-model classes, with UI-specific validation, property change handlers for WPF, etc.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I've always done Linq to SQL which I like. It's easy to setup and work with. I follow a typical n-Tier architecture: UI <--> BL <--> DAL <--> DB I've only set up Entity Framework once. When it generated the Data Context all the entities were in the same DAL project. This means that my UI, BL, and other projects in the solution all needed a reference to the DAL. This seems like a tight coupling. I was able, with a lot of work, to generate the entities into a separate project. Then, the other projects in the solution only needed to know about the new entities project, but again it was a lot of work to set up. So, how is EF typically used? What's the right way to set up the DC and entities? Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Not if you lean on interfaces and follow the repository pattern to wrap your EF DataContexts. I generally throw a "core" or "common" library into my solutions to serve this purpose, and MEF my repository into the mix. This is also nice because it does not marry you to the EF implementation. Yes, you will be coupled to an abstraction, but that's more or less the point in my eyes.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
