Folks,
I am brand new to asp.net web APIs and need your help, I am using mvc4 Empty webapi project, I have a single controller called recordsController.
I have data that I need to persist in memory, and would like to use dependency injection to access this data model in my controller when a request arrives.
Is there any built in dependency injection that I can use ? if not, what is the best quick and dirty to accomplish this ?
Thanks in advance
DO you want DI or data persistence, they are not the same thing at all.
If you want to use shared memory between all requests without using some kind of backend (Database,file and so on) then check MemoryCache -> https://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache(v=vs.110).aspx
DI is used for runtime type resolution and has nothing to do with data persistence.
https://en.wikipedia.org/wiki/Dependency_injection
Related
I am using hibernate to persist data on a MySql database.
Now I am already configuring what my business model is in the hibernate configuration file.
What I am looking for is, are there any tools that on building/deploying the application will generate the Model Layer (POJOs), Persistence Layer and the Service Layer (Business logic) for the controllers to communicate with the database server. In short I wish to generated all the basic essentials from a single configuration point.
Ant or Spring or combination of other frameworks, anything that can achieve the solution.
Any reference to an existence thread or a handful document would be highly appreciated.
Thanks in advance.
Your closest bet is Grails.
I'm not a fan of what you'd like to do. Code generation can result in a brittle system.
spring roo can be also good option to look at as your stack is based on spring framework.
Another option which can be used is MyEclipse IDE for Spring this supports code generation based on domain/table.
I will start to code a new Web application soon. The application will be built using ASP.Net MVC 3 and Entity Framework 4.1 (Database First approach). Instead of using the default EntityObject classes, I will create POCO classes using the ADO.NET POCO Entity Generator.
When I create POCOs using this tool, it automatically adds the Virtual keyword to all properties for change tracking and navigation properties for lazy loading.
I have however read and seen from demonstrations, that Julie Lerman (EF Guru!) seems to turn off lazy loading and also modifies her POCO template so that the Virtual keyword is removed from her POCO classes. Julie states the reason why she does this is because she is writing applications for WCF services and using the Virtual keyword with this causes a Serialization issue. She says, as an object is getting serialized, the serializer is touching the navigation properties which then triggers lazy loading, and before you know it you are pulling the whole database across the wire.
I think Julie was perhaps exagarating when she said this could pull the whole database across the wire, however, even so, this thought scares me!
My question is (finally), should I also remove the Virtual keyword from my POCO classes for my MVC application and use DectectChanges for my change tracking and Eager Loading to request navigation properties.
Your help with this would be greatly appreciated.
Thanks as ever.
Serialization can indeed trigger lazy loading because the getter of the navigation property doesn't have a way to detect if the caller is the serializer or user code.
This is not the only issue: whether you have virtual navigation properties or all properties as virtual EF will create a proxy type at runtime for your entities, therefore entity instances the serializer will have to deal with at runtime will typically be of a type different from the one you defined.
Julie's recommendations are the simplest and most reasonable way to deal with the issues, but if you still want to work with the capabilities of proxies most of the time and only sometimes serialize them with WCF, there are other workarounds available:
You can use a DataContractResolver to map the proxy types to be serialized as the original types
You can also turn off lazy loading only when you are about to serialize a graph
More details are contained in this blog post: http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx
Besides this, my recommendation would be that you use the DbContext template and not the POCO template. DbContext is the new API we released as part of EF 4.1 with the goal of providing greater productivity. It has several advantages like the fact that it will automatically perform DetectChanges so that you won't need in general to care about calling the method yourself. Also the POCO entities we generate for DbContext are simpler than the ones that we generate with the POCO templates. You should be able to find lots of MVC exampels using DbContext.
Well it depends on your need, if you are going to serialize your POCO classes than yes you should remove them (For example: when using WCF services or basically anything that will serialize your entire object). But if you are just building a web app that needs to access your classes than I would leave them in your classes as you control the objects that you will access in your classes through your code.
I am creating my first ASP.NET MVC 3 application, and my data comes from a data source I can access only via its REST API.
I will only be using READ-ONLY access at this point to the REST data source (no updating, etc.)
I would like to use the Entity Framework V4 to provide a Business Entity interface to MVC 3 without exposing it to the REST API.
I need to get something working quickly - so I don't have time to fully understand the Server Layer / UnitOfWork and Repository patterns just yet, although I plan to go there next.
I am willing to use a Repository class at this time, but not ready for DI / IoC container yet.
Any suggestions on where the RESP API calls go?
EDIT
Learned by asking this question that it is not necessarily useful to integrate an ORM with a REST API - See my accepted answer below.
An Object/Relational Mapper, or ORM, like Entity Framework has specifically been developed to abstract away a relational database. It might not be the right fit for REST calls.
You could instead build a repository class that encapsulates the REST call and exposes methods like IEnumerable<T> GetAll() or T GetyById(...).
I am using MVC3 for my application and I have a question about validation. I have a Business Logic layer that is separate from my web layer where I will have a function like CreateUser, which creates a new user for the application to use. I want this function to be accessible in two places: 1) Somewhere in a controller that makes use of it and 2) in a "Setup Data" program that inserts data into the system.
I want to make use of things like ModelState.IsValid to check for all basic validation, but this won't help me for my Setup Data mode (or any other mode that doesn't go through MVC). Is there any way I can still leverage this code, but to contain all validation in my BusinessLogic layer instead of in the controller without having the BusinessLogic layer rely on MVC?
Thanks.
It looks like this article about Service Layers has what I need. Other suggestions are still welcome. Thanks.
Note that the article on service layers still means that you need a dependency on the MVC assembly. After wrestling a bit with this myself recently, I'm now of the opinion that keeping things as separate as possible is a good design. In my model assembly, I have a services folder wherein from, say, a Create() routine, I validate and throw custom exceptions.
The service layer doesn't care who or how these exceptions are consumed. In your MVC app, map them into model state errors collections or whatever. Your design is all the more solid because your model assembly doesn't depend on some validation runner making appropriate use of MVC validation attributes, collections, etc.
I also noticed the article mentions a repository. I know it's all the rage these days but if you're already using an ORM like Entity Framework, a repository is really just a DAO. Reposity is the new Singleton.
I am developing an ASP.NET MVC app and I've been looking into using Data Annotations on my POCO's which are defined in my Service Layer. As long as I have a reference to System.ComponentModel & System.ComponentModel.DataAnnotations this is no problem and what I like about this is that it allows me to reuse my Service Layer in a Win Forms app.
I'm now looking to do some Remote Validation using Data Annotations and have taken a look at this article: http://msdn.microsoft.com/en-us/library/ff398048(VS.100).aspx
However, to use the Data Annotations in this context I need to reference System.Web.MVC,
System.Web and System.Web.Routing. This introduces a dependency on the Web DLL's, which
limits me somewhat.
Can anyone recommend a good clean way to implement Remote Data Validation using Data Annotations that isn't coupled with ASP.NET MVC or maybe suggest a better alternative.
Thanks for the help !
I resolved this in the end by backing away from putting DataAnnotations on my POCO's and instead I put them on my ViewModels and use AutoMapper to Map between my ViewModel and POCO (which saves me some time doing tedious mapping). There's a great video on Automapper here http://perseus.franklins.net/dnrtvplayer/player.aspx?ShowNum=0155