I am doing some prototyping and have a small database (4 related tables) which I developed an Entity Framework 6 project around (DLL with models for the tables). I've added an ASP.NET MVC 4 Web App to the solution that includes Repository interfaces/implementations under the model folder. The Repositories add interfaces for CRUD operations against the EF project. The Web App has a set of controllers providing REST interface through the repositories. Standard stuff I believe.
The issue that I have is I want to create an aggregate class the wrappers types (models) defined in the EF and return that aggregate in response to a Get request. The question is where do I define this aggregate object? The EF project? (and how?). An independent class library (usable by a client)? The Web App?
Trying to keep all the model definitions in the same place that understood by a client and Web App service at the same time.
Thanks
I believe what you want here is the DTO (Data Transfer Object) pattern. See here and here for basic explanation of the pattern. The idea is that you define a set of classes distinct from your data access objects (EF classes in your case), whose purpose is to relay data between your REST interface and its clients. If you have C# clients to whom you want to make the class definitions visible for simplicity then I would suggest putting the DTO class definitions in their own class library project and have the server and client both reference that dll.
Related
I am creating an application that has those three different projects:
ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)
ApiService has a reference to BusinessLogic
BusinessLogic has a reference to DataAccess
DataAccess uses Entity Framework with code first approach so it contains the models for the database tables.
My question is, what is the best approach or best practice regarding the models for Business and Service Projects?
I have read that Service project should not be using the models of the DataAccess project, so where should I create that models, in Service or in Business?
Thanks in advance.
Separate BL(Business logic)/Presentation layer models from DAL(Data access layer) models always.
Add one more layer between them which will do the mapping, use Automapper or somethogn custom. So when you are passing data to DAL models will be mapped to entity models, and when BL is getting the data from DALsame thing, map entity models to BL models,
Why?
The way how you are persisting your data in your database may be rather different from how you are going to present it to the user. The data may have to be obtained from several entities, joined by relationships, constructed at run time again by joining from other tables, etc. How you are going to present it to a user may be simplified and different than it is persisted, so you can hide that complexity which is needed for the database.
I don't know if this is best practice, but I have made many projects that contain a lot of shared logic and functionality between windows services, Web APIs, etc. They have all followed something similar to this:
Wrapper - Contains interaces, models, and code to make calling the WebAPI from another .NET project easier. Has no references to the other projects at all
Core - Contains all the meaty business logic. Service layer, data access layer, helper classes, etc. References Wrapper and anything else needed to function
WebAPI - Contains only code necessary for creating a WebAPI around the service layer functions in Core References Wrapper for models/interfaces, and Core for business logic
Other projects that use Core would be similar to the WebAPI one. Examples would be a console app for scheduled tasks, Windows service for continual data processing, etc.
This results in what I've seen some people refer to as a "mega solution" or similar, but so long as you're keeping your code to one domain you're not creating a mess.
I am building an asp.net mvc application that is using Entity Framework 6. We have the challenge of building several implementations of this same application. So we have created a core library called MyApp.Core which contains the following:
DbContext
Models
Customer
Product
(other models)
Repositories
We have the need to extend models for different implementations of the application. For example we might want to put SomeProperty on the customer table for 1 customer and SomeOtherProperty for another customer.
How can we improve the structure so it doesn't break the EF code first migrations? Or cause any other issues?
Should we just have a unique ASP.net project for each customer that references the MyApp.Core? And should we reference those via a nuget package? Or something else like a git sub module?
Any suggestions on the organization of the custom implementations of this type of structure?
Your solution may be an IsA (Is-a, is a) database structure that can be created from your code-first model using the TPC method mentioned here:
http://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines
You might create an abstraction such as ICustomer, or CustomerBase which contains a reference to a table containing the implementations of your application (is that Product?).
You might also transform your Customer class into a base class, and other classes with additional fields would inherit from it.
In either event, the article deals with bringing code first into a database model that can handle this kind of thing. You may also want to take a look at multi-tenant architecture, just to say you've done your homework. That's here: https://msdn.microsoft.com/en-us/library/aa479086.aspx
Please bear with me as I am new to MVC and WCF and may be asking the wrong question.
I am trying to write a WCF service and an MVC web application over an existing project that contains entity, data and business layers. The MVC and WCF components would then replace an older web service and WebForms application which worked very diferently and did not use modern practices.
I see the need to generate DTO objects against all Entity objects and was wondering how we can generate them. Through reflection, digging into the DbContext or some other method.
Furthermore, I also want to generate repository partial classes minimizing the need to maintain hand-written code for a large data model.
How do large development teams do this?
Currently I'm working on a project which is using WCF directly to interact with Service functionality instead of WCF RIA. The problem is I create Model for each Entity (in service) inside silverlight client application for validation, That's OK. But I should populate Server Entities with Client Models each time I want to Insert or Update an Entity in database. Is there any way to prevent these extra works?
A typical first version of an MVVM (Silverlight) Client and (WCF) Service has a lot of duplicate types, logic and mapping between types.
This is one of the reasons why WCF RIA Services has been created.
In a first version of an MVVM application the Model and ViewModel will be very similar. When new requirements appear and the Views get more and more functionality added these will diverge and the Model will become very different from the ViewModel.
The Model will be determined by the the service and the ViewModel by the Views. This will cause the mapping to be less and less trivial.
I have used T4 templates to generate ViewModels based on XML definitions. This prevented the need to write the boring, repetitive mapping code.
EDIT
See the MVMMapper project on Codeplex for the generation of ViewModels using T4
Given that directly exposing linq to sql or entity framework classes over web services is a bad idea, how should I expose the data over a web service such as WCF?
It seems like I would have to create a parallel set of classes for the web service, and then marshal the data into those, which doesn't seem very elegant.
The web services will be custom, so something like RIA is not very useful in this case.
You can use the support for POCO (Plain Old CLR Objects) in EF 4 to expose the entity model as simple objects. The designer supports converting entity data model into POCO objects.
Specifically for WCF service scenario, you could also use the self tracking entities T4 template available in EF 4 when you try to add new item to the project.
I hope following link will be helpful to you
http://blogs.msdn.com/b/efdesign/archive/2010/03/10/poco-template-code-generation-options.aspx
http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx
Generate POCO classes in different project to the project with Entity Framework model
Have you seen OData and WCF Data Services? Here is a great talk by ScottHa: http://www.hanselman.com/blog/ODataBasicsAtTheAZGroupsDayOfNETWithScottGu.aspx
OData, through WCF Data Services, works seamlessly with EF 4.