I have some questions regarding the use of Database First Model and Catel. I have read the documentation and it seems like its based on a Code First design for models. I have also the limitation that other people are working on the same model and not using Catel as framework. So how could i use those models as base for my catel view models? Is there an example on how to do it properly?
You don't necessarily have to use Catel models as base models when using the EF stuff inside Catel.
If you don't want a reference to Catel for other assemblies, I would create a contract assembly (with interfaces for all services, etc) and only use Catel inside the actual implementation assembly.
Related
I am using Entity Framework and would like to use TPH with interfaces. So I have a created an interface, "ICustomer", which maps to "SimpleCustomer" and "DiscountedCustomer" class as shown below. Below is the model builder code. From what I understand we can not use interfaces with Entity Framework, so what's the best way?
modelBuilder.Entity<ICustomer>().ToTable("tblCustomer")
.Map<SimpleCustomer>(x => x.Requires("CustomerType").HasValue("S"))
.Map<DiscountedCustomer>(x => x.Requires("CustomerType").HasValue("D"));
My application uses interfaces all over the UI and would like to have a smooth type casting to Entity Framework. So is what the best way?
Entity Framework does not support TPH with interfaces (sorry for stating the obvious). This may not be the solution you are looking for, but I am still going to put it there because it seems to be the only solution as of 16 April 2015.
In Entity Framework 6, the closest you can get is - Use abstract classes instead of interfaces. This article talks about TPH in EF in great detail.
My suggestion is if you want to use interfaces and maintain the hierarchy and also still want smooth typecasting, consider using automapper with abstract classes. This way your UI will still use Interfaces, but can be mapped to domain model using automapper profiles. Atleast till the interface support arrives. It will not be a quick one if the application is large and has hundreds of domain models, so need to plan it wisely.
If you are creating it from scratch, you can simply use abstract classes from UI layer to DAL without any re-factoring.
I'm developping a line of business application using WPF as a presentation layer (of course with MVVM).
I'm using ADO.Net Entity Framework to map the DataBase.
I don't want to use entities directly in code (in the business layer). I want to separate my project into 3 layers:
Presentation layer
Business Layer
Data Access Layer
According to this post I want to implement a full encapsulation of the Entity Framework to provide a separation of concerns and to not be dependant on EF as ORM in the future.
Can you help me by giving me some exemples to encapsulate the EF and how to implement this in code.
Regarding this
I want to implement a Full encapsulation of the Entity Framework. to
provide a separation of concerns and to not be dependant on EF in the
future as ORM
Normally, you will create yourself a lot of problems if you go that route. If you choose EF, you really should make full use of the features, not hiding that behind another abstraction.
EF itself is already an abstraction layer over DB, there is no need to create another abstraction on top of that.
I would take a look at this post wich implements UnitOfWork and Repository patterns to implement what, I understand, you want to achieve.
http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx
There is one way of doing it, using POCO. Entity Framework 4.0 comes with the support of POCO (Plain CLR Objects). But POCO has its own complexities, when u have to deal with Relationship and associations. You can refer to the blog by Julie Lerman (a nice article)
http://thedatafarm.com/blog/data-access/agile-entity-framework-4-repository-part-1-model-and-poco-classes/
I guess that EF4.1 is recent to EF4.0, but I didn't find any book on EF4.1, but 2 books on EF4.0.
can I still buy the book on EF4.0 expecting that I will get most of the concept??
Thanks for helping.
According to The ADO.NET Team blog, there are two main features:
The DbContext API is a simplified abstraction over ObjectContext and a number of other types that were included in previous releases of the ADO.NET Entity Framework. The DbContext API surface is optimized for common tasks and coding patterns. DbContext can be used with Database First, Model First and Code First development.
Code First is a new development pattern for the ADO.NET Entity Framework and provides an alternative to the existing Database First and Model First patterns. Code First is focused around defining your model using C#/VB.NET classes, these classes can then be mapped to an existing database or be used to generate a database schema. Additional configuration can be supplied using Data Annotations or via a fluent API.
EF 4.0 books are good unless you are using one of those 2 features, because you won't find them in there.
But you have plenty of resources online about those new features (especially Code First).
You even have official tutorials:
Using DbContext
Code First walkthrough
It seems that most of the focus with MVC3 and EF4.1 is around "code first" - I can't seem to find any examples or tutorials that meet the following criteria:
uses an existing SQLServer database
has separate projects for web & data access (we will have multiple web apps sharing the same data access classes)
recommendations for validation
Does such an example or tutorial exist? Are there any documented "best practices" for how to accomplish this, or rationale for NOT having a solution structured this way?
It is quite common scenario and it depends if you want to use EDMX file for mapping or if you want to have mapping defined in code (like code first).
Both scenarios can be done as database first
You will create EDMX from existing database with build in EF tools in Visual Studio and you will use DbContext T4 generator template to get POCO classes and DbContext derived class
You will download EF Power Tools CTP and you will use its reverse engineering feature to generate code mapping, POCO classes and context for you
Neither of these approaches will add Data annotations. Data annotations on entities should not be used for client validation (that is bad practice) unless you are doing very simple applications. Usually your views have some more advanced expectations and validation in view can be different then on entity. For example insert view and update view can need different validations and it is not possible to perform it with single set of data annotation on the entity. Because of that you should move data annotations for validation to specialized view models and transform your entities to view models and vice versa (you can use AutoMapper to simplify this).
Anyway it is possible to add data annotations to generated classes via buddy classes but as mentioned it is not a good practice.
What is the importance of POCO support in Entity Framework?
Maybe its better to ask What is the uses of POCO ?
Actually POCO is similar to POJO (Plain old java objects) in .net world. POCOs are objects tha don't have to follow any particular conventions (implementing any interface ,extending any class,having special attributes or naming convention etc.)
Some of the persistent frameworks force us to use specific interfaces or attirbutes , abstract classes. This is not a problem as long as you are working on a project from scratch and you are choosing which framework to use but if you are working on a legacy system and want to change its data access layer to use a persistent framework , it might have a negative impact.
Realy short:
That you have objects that didn't know anything about the EntityFramework but are bound to it (Bound to the context so that the EntityFramework can take care).