I'm going to develop a web-based system with MVC4 which will use web services (WCF, exactly) for getting data from data provider (I can't use direct connection to SQL)
So, I have a question about using the web services in this project. Is this correct to use directly web service models as MVC model or I should create separate models for my MVC project and then map web service models to the models in MVC with an object-mapper (such as EmitMapper)?
Note: Consider that the web services may changes a lot.
No, don't use your WCF serializable proxy classes as MVC Viewmodels - this will couple the SOA back end to your MVC front end unnecessarily.
The 2 classes have entirely different concerns - e.g. you may want to decorate your ViewModels with DataAnnotations like UIHint etc which aren't applicable to your WCF classes (and similarly, your WCF Proxy classes may have serialization attributes).
Also, as your screens evolve, you will typically find that you may need to diverge the 2 models significantly - e.g. your screens need properties which your Service doesn't need, and vice versa.
So yes, separate classes for WCF data serialization and for MVC ViewModels, and as you've suggested, if you keep to a standard naming convention, mappers like AutoMapper will do most of the work for you.
I can only tell you what I would do.
Keep the models separate. As you say, the web services may change a lot. Having a halfway house may shield you from a lot of the implementation churn.
Also worth pointing out that:-
Easier to move to a different solution ( use a different strategy to populate the model )
Easier to unit test ( don't necessarily need a net connection to test that your model works )
Related
I am new to Web API2. My solution has 3 projects (MVC, WebAPI2, Class library for EF). I have below doubts.
1) Have kept WebAPI and MVC as separate projects for separation of concerns. Is it advisable or it is better to keep both in single project?
2) With WCF we can take service reference in MVC to avail all DB class models so that it will be easy in MVC to scaffold the controllers and to add Model validations. How to do that with Web API2 as I will not have reference in MVC for DB classes. Do I need to create duplicate DB class models in the MVC project for scaffolding purpose and model validation purpose?
Your title confuses me a fair bit, but model validation can be done with validation attributes. I will try and answer the questions in the body of your question post.
It depends on how you expect to use your MVC and WebApi projects.
Keep in mind you may make things easier for yourself if they in the same project so you don't need to worry too much about RPC. But who knows how you intend to use them.
WebAPI is normally used for integration with systems other than your own. For this reason (de)serialization and request/response handling is highly customizable. The models used for the WebAPI controller are often specified or provided to the system the interface is intended to integrate with.
The model used for the WebAPI or MVC controller should be separate to the entity model for your ORM. The reason you would want to do this is that the data in your entity model does not always fit the use of the view or the validation of the view model that is sent back to the controller from the view.
In both cases the models that interface your WebAPI and MVC controllers should be designed to accommodate your use cases and should be fairly decoupled from your entity models for persistence.
So to answer your second question you probably only need one set of entity models and probably only one dbcontext implementation, but have all of that in its own project so that if you do have separate MVC and WebAPI projects they both depend on that EF project.
I recently started learning about ASP.Net MVC and its various features MVC_3_MUSIC_STORE +
CODE .
It looks very structured and simple to understand.
I was reading about enterprise applications and how they are layered/tiered in different sections
(logical/physical)
I was wondering(for learning ) how to do separate(convert) the above MVC_3_MUSIC_STORE into n-tier or 3 tier application (since we already have a working example) in order to have a clean separation of concerns.
I don't have much prior experience in this.
What changes would be required?
What will be different DTO(s) or POCO(s) that would be needed?
The above example uses POCO entities around from controller to views.
Would it remain same, assuming EF Code first is used.
Also i was wondering what changes will be required if WCF Webservice is introduced as a data access layer. i.e.Instead of retrieving data from DAL ,Clients will request data to and from WCF Webservice. Client can be Web app or WinForms or Sliverlight app.
( [DAL <--> WCF WS] <--> N CLIENTS)
Would be interesting to know about various approaches.
Example code would be helpful and/or examples for same.
Edit 1 - Added
One of the things I noticed was when i move the model classes from Model folder to new project "MYMODEL" I will have to again add reference to "System.ComponentModel.DataAnnotations" and "System.Web.Mvc" in new model project?
How can this be avoided? How can these validations be moved to Business layer?
Edit 2
Looking for something similar to this
Advice For A Newbie About N-Tier Applications
Normally the only change that will be required is that you will provide an implementation of the repository (DAL layer) which will call a WCF web service to fetch the domain models from instead of some EF DataContext talking directly to the database. A change completely transparent to Controllers and Views.
I'm in the process of doing the analysis of a potentially big web site, and I have a number of questions.
The web site is going to be written in ASP.NET MVC 3 with razor view engine. In most examples I find that controllers directly use the underlying database (using domain/repository pattern), so there's no WCF service in between. My first question is: is this architecture suitable for a big site with a lot of traffic? It's always possible to load balance the site, but is this a good approach? Or should I make the site use WCF services that interact with the data?
Question 2: I would like to adopt CQS principles, which means that I want to separate the querying from the commanding part. So this means that the querying part will have a different model (optimized for the views) than the commanding part (optimized to business intend and only containing properties that are needed for completing the command) - but both act on the same database. Do you think this is a good idea?
Thanks for the advice!
For scalability, it helps to separate back-end code from front-end code. So if you put UI code in the MVC project and as much processing code as possible in one or more separate WCF and business logic projects, not only will your code be clearer but you will also be able to scale the layers/tiers independently of each other.
CQRS is great for high-traffic websites. I think CQRS, properly combined with a good base library for DDD, is good even for low-traffic sites because it makes business logic easier to implement. The separation of data into a read-optimized model and a write-optimized model makes sense from an architectural point of view also because it makes changes easier to do (maybe some more work, but it's definitely easier to make changes without breaking something).
However, if both act on the same database, I would make sure that the read model consists entirely of Views so that you can modify entities as needed without breaking the Read code. This has the advantage that you'll need to write less code, but your write model will still consist of a full-fledged entity model rather than just an event store.
EDIT to answer your extra questions:
What I like to do is use a WCF Data Service for the Read model. This technology (specific to .NET 4.0) builds an OData (= REST + Atom with LINQ support) web service on top of a data model, such as an Entity Framework EDMX.
So, I build a Read model in SQL Server (Views), then build an Entity Framework model from that, then build a WCF Data Service on top of that, in read-only mode. That sounds a lot more complicated than it is, it only takes a few minutes. You don't need to create yet another model, just expose the EDMX as read-only. See also http://msdn.microsoft.com/en-us/library/cc668794.aspx.
The Command service is then just a one-way regular WCF service, the Read service is the WCF Data Service, and your MVC application consumes them both.
I'm building a Silverlight app that I want to be hosted in Azure and use Azure table storage.
I have a class that represents the main data entity, ExpenseInfo. It has many data annotations for RIA validation, such as [Required].
I am following this tutorial to set up the REST service for access from SL. It wants there to be a class in my web role for data serialization. This class would contain all the same data as ExpenseInfo.
So, where do I want ExpenseInfo to be? Do I want separate classes in each project? Put it in one project, and instantiate it in both? Is it weird to have a class with all those data annotations in the server side web role?
Thanks, I'm new to SL and Azure.
The pattern you're looking for here is the Data Transfer Object (DTO) pattern. Here's a good article on the pros and cons of that pattern. Personally, I don't mind the additional classes that a DTO and/or and Adapter pattern brings (you will see adapter type patterns used all over the place, MVVM is a hot one right now). I have a strong dislike for sharing business logic in assemblies across a trust boundary, so I generally use DTO/Adapter in my architectures.
I have a fairly clean ASP.NET MVC project structure. However, I'm struggling on how to organize the mass of classes which are DTOs (data transfer objects), e.g. just to encapsulate post data from forms (viewmodels) but don't represent full domain objects or anything near that yet; and then the many "result" objects I have which communicate complex result information from my service layer back to the controller. Where do you stuff these/how do you organize them? I have one folder with well over 60 classes now and it's getting cluttered. Appreciate suggestions!
Domain objects should live in a separate Domain Model library. Anything that supports the Domain Model in an framework-neutral way (e.g. no references to ASP.NET MVC, WCF, WPF etc.) belongs in the Domain Model.
Classes that perform translation between the Domain Model and the specific interface framework (ASP.NET MVC in your case) belongs in that particular project (your ASP.NET MVC project).
You can have your mappers etc. in a separate Mappers folder, but personally, I think it is much more valuable to structure code along features instead of infrastructure.
I use <CompanyName>.<ProjectName>.Core to store all project specific classes which are not strictly pertaining to the particular project interface that I am writing. So DTOs, DAOs, other project-specific classes are all in there.
I also use <CompanyName>.<DotNetLibraryNamespace> to store general purpose classes that could be reused across projects, and are not specific to this project domain. For example, string manipulation classes could go in the <CompanyName>.Text namespace. I always mirror the .net namespace structure names so that anyone that uses the .net class library has an easy time finding my stuff.