I want to build a MVC application that consumes both REST and SOAP references. I can use the added references as the model but I cannot add attributes like I would be able to if I created the class myself. I want the ability to add [DataType], [Display], [Required], etc... to the properties.
Is there a way to make a wrapper around the existing model/class from the API and add my own attributes?
In my opinion it would be easier if you create your model with those attributes and the try to map what you've received from your services to your model. You can use AutoMapper that will make your life easier too.
Related
When using Entity Framework with Code-First, what is the best practice when calling database data?
This is my first time using Entity Framework with MVC and noticed that it automatically builds Models in my DataLayer. I also have the basic Models within my MVC UI which allow me to manipulate and display the data within my Views. I currently grab the data using my Workflow layer, and then AutoMap the Database Model to my UI Model to display the data.
Is this the best practice? Should I be using the Entity Framework Models instead of my UI Models? Or this even possible to do cleanly?
Any information on the matter would be appreciated.
It's up to you really. If you like to re-use the same EF entities for your view models as well; go ahead. Personally, I prefer not to. This is because you normally end up adding a bunch of properties to the class that have nothing to do with what's stored in the data and yes; I know you can use the NotMapped attribute like this:
[NotMapped]
public string MyExtraProperty { get; set; }
but I prefer not to. Additionally, you end up adding [Display] and other attributes to your properties and before you know it, you've got something decorated with both data specific and UI specific attributes and it can get messy if you're not careful.
So for me; I have the following:
Domain Entity
View Model
Service/Facade/Repository
Controller calls repository to get the domain entity and converts it to a view model for displaying.
I find that to be a cleaner approach, but maybe that's just me.. the most important thing is to just choose one way and stick with it for the sake of consistency and clarity of code, but either method is acceptable.. "whatever floats your boat" as they say...
The POCOs created by EF are supposed to be used as your model. The general idea is that you have EF providing access to your database. You query EF using LINQ and/or extension methods and end up with an object or collection of objects that you display on your UI by binding them in WPF. That is of course if you're using WPF as opposed to the older WinForms. I can tell you from experience that it's a very streamlined process once you become familiar with the technologies. That's how a very basic setup would work.
A more advanced way of going about it is adding architectures like Model-View-ViewModel (MVVM) and possibly the repository pattern into the mix at which point you get better separation of code and presentation at the cost of increased complexity.
I don't know what flavor of MVC you're using and how it can be made to intermingle with the above, but if you want to know more about how EF was envisioned to work you should look into the technologies I've listed above.
This is a very simple Web API project. I have a data model, generated DbContext, and a controller.
When I add the [JsonIgnore] attribute to certain properties on my model classes and then later make a change to the data model, the model classes get regenerated and my [JsonIgnore] attribute is deleted. I understand why this happens and that I shouldn't be adding attributes to an auto-generated class. My question is, where should I be annotating classes with attributes, like [JsonIgnore] for use with ASP.NET Web API?
ASP.NET Web API 4, RTW
You should use view models. Basically define classes that will contain only the properties that you need to expose and then return those view models from your Web API actions. This way you don't have to worry about polluting your domain models with [JsonIgnore] attributes especially if you don't want those properties to be ignored only for certain actions. In order to simplify the mapping between your domain models and view models you may take a look at AutoMapper.
Because you say explicitly that you are creating a very simple Web API project, you might be able to get away with a simple global replace. While I was converting a project to use ASP.NET Web API, I ran into the same problem. Because I was changing the Database Schema regularly it was simply easier to return the original types rather than dynamic or strongly typed view models since the properties of the data being wrapped was constantly changing.
The properties that needed to be ignored for serialization happen to be all the Navigation Properties generated by EF. It also happens that all these properties are virtual. I did a replace in files (scoped to only my data library project) replacing all public virtual with [Newtonsoft.Json.JsonIgnore] public virtual.
A quick and easy fix to allow testing while the project is still in development. I agree that in the end, you should probably wrap the EF models into view models, but this simple method can allow you to keep working without them for a bit longer.
I’m working on a Grail’s project that has some Domain objects not persisted on the database. They are managed thru a REST API, so all their CRUD operations will be done with this API instead of the database.
The point is to still be able to use some interesting Grails plug-ins (like searching using Compass).
For instance, the administration the Domain objects Users is going to be managed with the REST API, so when the Users list is displayed a the REST method to retrieve the list of users will be invoked on the remote server. I hope this use case is clear enough :)
I can think on several ways to design that but I'm not sure what’s the best:
Should I create the Domain Objects in the controller (and delete the
previous Users stored in memory)?
It seems it’s possible to define a Domain Class not persistable (with
mapping I think) but I’m not sure if this is the best approach or
where to load the data.
It is better not to model as a Grails the User as Domain object?
Thanks in advance!
I would wrap the REST interactions in a service, and call the service from a controller. In that case, the service would get the response and create its objects, passing the list back to the controller. Controllers should just handle incoming requests, invoke application components, and return responses.
It seems you want models to represent the data in the other application, which is a good idea. Since you don't need GORM, you might want to define them in the 'groovy' folder of your app instead of the domain models folder. Then I think they will just be objects.
I'd go with non-domain objects in src folder - though, need to check if it's possible to use the mentioned plugins with them.
I wonder what domain class functionality you wish to get out of non-persistent classes?
I'm building a concept application with MVC 3 in an attempt to learn its ways. I've previously done some very heavy-duty applications in WebForms, using an n-tier approach, usually consisting of domain objects with repositories for storage and services to manipulate them before storage.
I'm trying to reconcile how I used to do things with the "right" way to do them in MVC, if there is any one such way. The thing I'm getting hung up over right now is when to use ViewModels versus when to use my domain objects that are in a whole other project. Validation is done with ViewModels, but as I write more customized, business-logic validation, it seems like it's too much responsibility on a lowly ViewModel that was just there to help me move data around before storing it officially in the database through the repository layer.
I'm also getting tired of mapping ViewModel data to the "official" domain object that the repository stores and retrieves, but I feel like I shouldn't tarnish my domain objects with the MVC attributes for validation, either.
Do you have any advice for where to draw the line between domain objects and mere ViewModels? Or am I complicating things, and my ViewModels should actually be the "official" models that the repository stores?
Do you have any advice for where to draw the line between domain objects and mere ViewModels?
Personally I always use View Models. All UI validation logic is done on the view models (required fields, ...) and business logic on the domain models (username already exists, ...). I also use AutoMapper in order to not get tired of mapping between the domain models and the view models that are passed to the view.
I generally default to using View Models, though for read-only views, I have been known to use the domain model (no reason to go through the overhead of mapping if I am only going to read data out of it).
If you do decide to use domain models, I would never let MVC bind directly to them, because if someone knows your domain well enough, they can post values that bind to properties you do not want the user to be able to edit. You can define white and black list of properties of what model binder can and cannot bind to, but utilizing that is something else you'll have to maintain and something that can easily be forgotten about.
I think the best approach is to use view models ALWAYS. These are about presentation concerns and should be where basic input validation is handled. Domain objects are not appropriate for this.
I use specific view models per view and only include the information that is needed in the view - keeping view models totally view-centric makes for nice clean views.
You can use Automapper to help remove the drudgery of moving between view and domain models.
Can I recommend ASP.NET MVC 2 in Action as a great book for strong ASP.NET MVC patterns. This covers using Automapper in detail.
Domain models and ViewModels will look very much like each other. However, ViewModels usually contain view logic attributes and properties. Also sometimes data type can be different, for example you might need to define a DateTime property as string just get the validation working without raising any errors.
I am using AutoMapper to convert from Model to ViewModels/vice versa.
ViewModel are good but don't forget Validation attributes are not only limited to MVC projects, you can use them in any .net project. Because of this it can make sense to apply the validation attributes to your domain objects, preferably by using a partial class and/or a Validator class http://weblogs.asp.net/scottgu/archive/2010/12/10/class-level-model-validation-with-ef-code-first-and-asp-net-mvc-3.aspx
My approach is that a ViewModel model should be associated to a single view (or least a set of related views), and is usually a sub-set of your domain model. I see a ViewModel as responsible for UI validation, where as your domain object is responsible for business rule validation.
As for mapping between the two, highly recommend using Automapper which can automatically map properties based on conventions, it's a huge time saver.
I´m new to ORMs and I have a new project I´ll do in .Net MVC.
In the Model Layer I´ll create my classes: Videos and I´ll work with APIs as a DataLayer (BrightCove & YouTube APIs).
So, I dont have a Relational Database as a Data Layer. Is it possible to work with an ORM (as Subsonic)?
Thanks!
Pretty sure this isn't do-able. Or at least it's not the intention of an ORM.
If you're dealing with an api you'd be making a call and getting back a result yes? or you'd make a call and then get values from properties?
Either way there really isn't anything for the ORm to map from. It has no idea on calling api's etc. They are given objects that they can interpret using reflection (i assume) etc.
So I think you'll need to create an object yourself from the API, in which case you probably don't need an ORm in this case. Unless you create your API model in a layer of some sort and then use an ORM to translate to a model used by the application. This would be a better solution because if the API model changes the changes to your code would be minimal.
There is a .NET API for Youtube that provides classes for videos as well as data access methods to get data from Youtube. I think unless you have a good reason to roll your own, you might consider using their .NET API and directly using or extending the classes they provide. If you want to abstract out the data access, you could create your own Video class with just the properties you need and implement your own video repository which uses Youtube's API to hydrate instances of your class.
In the SubSonic code (just download it from github) there is a neat method in the SqlQuery class that is called "ExcecuteTypedList()".
It is just a small method that uses reflection to map a result from a DataReader to a generic class. It's simple but brilliant.
You could look at the code and modify it for yourself to fit your needs.
It basically does the following if you call ExecuteTypedList()
create an instance of your class
for the parameter "Test" it tries to load the property "Test of the class instance
Sets the value