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?
Related
I have a mvc web application which consumes web api service. If I want send complex form data represented in MyModel from mvc to the webservice, should webservice have MyModel as part of the project.
This way I would have MyModel on both projects, mvc and web service. Is this right approach?
In my opinion they should have different models and do the necessary mapping to avoid interdependent. In this case both projects ended up intact. This approach is called Data transfer object (DTO).
Benefits
You only care what you need thru mapping
No be big effect if model in different project change
Obviously you will not be tied up on other model outside of your domain
Disadvantages
You will end up many models
Expensive process
You will appreciate DTO specially if you're working in different teams working on different parts ex. One team woking on views and different team for backend. Also if your consuming external APIs. But you can apply this approach in your case.
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.
I'm new to using the ASP.net MVC framework (and C# too). I have more experience using JSP + JSTL MVC framework. I want to know how to run custom queries if I need to do more complex sql.
In the JSP framework, I'm used to creating DAOs to query sql tables which doesn't seem to be the case in ASP.net. For ASP.net, I noticed that we use LINQ to do the querying over a DBSet object from a model.
My Questions:
Where do I write the custom query code? In the model?
How do I write it? Is it through some sort of db.execute statements?
Are there any configuration changes I need to make?
Examples and other resources would be nice.
I tried looking through the asp.net MVC tutorials on asp.net, but I couldn't find anything.
How you execute SQL queries depends entirely on what data access framework you are using. You can write plain SQL with ADO.NET and execute queries in a manner much like that you would expect.
In answer to the second part of your question, this should be done in a data access layer and be completely unrelated to your ASP.NET MVC application itself. Any necessary logic for instantiating and communicating with classes in that abstracted layer should reside in your controller (and, ideally, be loosely coupled from your application via the use of interfaces and/or service layers).
In this sense, yes, it belongs in the model. However, bear in mind that, conceptually, the 'M' in ASP.NET MVC is the domain model (i.e. the aforementioned data access layer), not the view model. The view model is just an independent wrapper that is designed to store relevant data for a given view and should - in most cases - be completely devoid of logic whatsoever.
In the JSP framework, I'm used to creating DAOs to query sql tables
which doesn't seem to be the case in ASP.net.
It is very much the same, you should have a separate DAL project with your DAO objects and reference those from your Business Layer (another separate project). The ASP.NET MVC project itself will add a reference to the Business Layer project which in turn will add a reference to the DAL. That way, you can keep a 3-tier architecture:
UI (ASP.NET MVC project)
|
|
Business Layer (POCO objects (= to POJO), validation, biz logic) - separate project(s), depending on whether you put your POCO objects in the same project or not.
|
|
Data Access Layer (You can use ADO.NET, EF (LINQ), etc.)
An ASP.NET MVC app usually is composed of 3 folders: Models, Views, Controllers but everything that's typically placed in the Models folder is really your Business Objects so I tend to get rid of that folder completely and I am left with just the Views and the Controllers folders. The views are just the html markup, pretty much. The Controllers classes simply call the methods from the business layer and passes the results to the views. So for example, a UserController class will look something like this:
public class UserController : Controller
{
public ActionResult Index()
{
var allUsers = UserBusLayer.User.GetAll();
return View(allUsers);
}
}
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
I'm learning MVC. There are plenty of sample codes working with SQL Server. The coder has the database created on the fly from his/her classes, which enables a very clean and rapid development workflow.
I'm working with Oracle DB.
Can I also abstract data from tables, that I already have? I don't need to abstract all columns(i.e. i need only two of 50). I need only read access and wanna use either web service or oracle as input.
You know any sample code, so I can see how can abstract data for web-service or oracle as data source?
You could take a look at Entity Framework. It allows you to abstract your data access code from the underlying database. This really is not MVC specific and you could use it in any .NET application you wish.
As far as web services are concerned I would recommend you designing a data access layer that will be called from your MVC controllers and which would delegate the calls to the underlying web service. An abstraction over this web service would be beneficial if you want to unit test your controllers in isolation.