I would like to build a new web application using ASP.NET MVC3 and MongoDB. I've seen many examples online and even built some working code myself, but I am wondering about how I should set up my application. In the MVC examples which use Entity Framework, they place everything in a Models folder. I think I will do the same but where should I put my queries etc. Should I abstract them to a better location. I'm somewhat new to making C# applications and the .NET world, so some of the "ways" are not clear to me yet. Also, does creating the database object (where I tell it mongo's server address) each time I need it have performance impacts? Can I just connect once and then talk through that object? Does it really reconnect every time I perform that action?
Thanks!
Normally, in your Model, you have an object model representing your domain.
With MongoDB, this does not change. Your objects in your model will still have properties and behaviors.
What will change, is that instead of storing each object in a table in a relationnal model, you will be storing a graph of objects. Let's say you have an invoice. You will store the Invoice, with all the lines of the invoice as a single record. That's about it, not really more complicated than that.
First of all, don't use your domain objects (these that you supposed to save to RDBMS using Entity Framework or to MongoDB) directly in ASP.NET MVC views! Use viewmodels instead. Then you will have Models folder in ASP.NET MVC project and separate project for your domain.
I didn't work with MongoDB before, but I suppose the best way to have database object per http request. Here is discussion on stackoverflow and here is video from 10gen about their C# driver.
Related
I've been tasked with making a web application that will display certain data from multiple databases/tables/views. I currently have been learning ASP MVC 5 to display data and I've been able to successfully connect to a database and display the information needed using Entity Framework 6. However, my issue is that this will become very tedious to continue doing this for multiple databases/tables/views even using scaffolding.
My current thought process is to go about making dynamic views/controllers or even have a way of programmatically creating views/controllers. I don't know if there is a way for me to create entity framework models at run time? I also don't know if there is better solutions out there to do something like this.
Follow up question, is it better to just use ADO .NET to access all this information? Or is there a way for me to just create a connection string and a new dbcontext/entity and then just connect to it that way without needing to generate the whole model?
Any help is appreciated!
If you choose to use Webforms and ASP.NET Dynamic Data, it will scaffold an entire database for you instead of scaffolding each controller one by one.
You can see more about it here: https://msdn.microsoft.com/en-us/library/cc488469.aspx
I recently made my first ASP.NET website with MVC. I selected the option that pre-loads a basic project with login functionality and a few pages. I spent a couple hours learning how it all works and I'm pretty comfortable with most of the features. Now I want to add a class that interacts with the database and I've run into a bit of an issue.
When I search for a solution every response says to use DbContext. I don't think there's necessarily anything wrong with this, but when I search for DbContext and some other commands that show up frequently in these responses, there are no instances of them in the project. I would really like to use the same method of creating models that was done for the account classes, but when I look at the code I'm not entirely sure what I'm looking at as it links to a bunch of different files.
Can I get some tips on how to create classes the way that ASP.NET creates default account models?
For reference: I'm using Web Essentials, Productivity Power Tools and VS 2013.5
There's tons of tutorials online that cover ASP.NET MVC Code First Entity Framework. I start with something like this
http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
And see where you get to. This is the basic approach:
Create the model classes
Create the Context
Enable Migrations (in case you need to change the model)
The SQL Expres database will be built automatically based on your EF classes.
Good luck. It's not a difficult as it first appears once you've done your first one.
I have a Web API application that uses one controller which returns data read from a file.
So all I'm using is the C (Controller) part of MVC. I have no Views, and I'm not using Models, either - I'm storing and retrieving the data to/from the App_Data folder.
I know this is a rather simple solution, but it seems that all I need is C, not MVC. Am I missing something?
Model-View-Controller is a design pattern, to help structure applications that have a GUI. ASP.NET MVC is a framework that helps you build a web application according to this design pattern.
Web API has nothing to do with the MVC design pattern. It was developed separately, temporarily distributed under the same umbrella name and now an own framework altogether: http://www.asp.net/web-api
The fact that some project templates still create "Model" and "Views" directories in your project, means that you're using an outdated project template or one that's assuming you want MVC and Web API in one project.
CodeCaster's answer already explained very well the "theory" behind your question. Although, I'll contribute with an answer because I stumbled into this months ago and it took some time to figure out why a recently created Web API project also had the Views and all the other items that a ASP.NET MVC application has.
The thing is in Visual Studio 2013, there's the Web Application template. When you select this option, a window is opened. In this window, there is an option for creating a Web Api. The problem relies here. When you select the Web Api in the window (Which of course it's what you want), for some reason it also mark the option for MVC in "Add folders and core references for" and worse, the checkboxe's are disabled so you can't "uncheck" it (so weird): This is what it looks like:
If you hit Ok at this time, the API is created with all the MVC references. Probably not what you want.
So, to create a "pure" Web API, that only has references for Web API related files and structure, this is what you need to do:
Select the Empty template and then mark the option for Web API. :
Consider that your controller has actions that will be invoked from a front-end application. The data being sent as the result of that call can be thought of as the model. The front-end app may then use that model to display a view. But you might also.do nothing of the sort. It is up to you as a developer to properly use the MVC pattern if that is the requirement.
Almost all software patterns start to make most sense as a project increases in size/complexity, and where the scenario in question mirrors the assumptions underlying the pattern. There are a number of trivial scenarios where the Model and View components are either implicit, provided by the framework itself or simply unnecessary. What the MS ASP.NET MVC does in essence is provide a framework that implements the basic MVC pattern within the MS web ecosystem. Whether you need to use the individual features (like EF modelling, Razor views) is up to you.
From your question, your requirements essentially are to allow access to a stored procedure and perform basic data transformation (via the POST) and then to return that data as JSON (via the GET). What is the necessity of the separate GET/POST requests? From your question, the GET relies on a preceding POST request. I would suggest that creating the intermediate JSON file may be unnecessary, rather just look up the data and pipe it back.
Should we not consider the data returned by the controller action as a view, A view of your data rather than a HTML view, the design pattern does not specify the type of the view. In my opinion its still MVC, the model still exists and you normally would create model of your data that you want to return, the view part is just an other model or view of your core model classes.
I have a Forms project that uses ASP.NET membership authentication to manage the users. I also have created model classes that use entity frameworks to populate a database. Currently, I have been planning on keeping the asp tables (membership and other records) in the same database as the tables containing the other application data.
When I run my program after changing some of the data model classes, entity frameworks recreates the entire database, and I've lost all my ASP.net tables.
What am I doing wrong here?
Without seeing, your code it is hard to say. Here is my wild guess.
You might have DropCreateDatabaseIfModelChanges. Basically, it drops the entire database when Code First classes change.
If so, you might want to replace it with NullDatabaseInitializer which prevents the schema from being altered.
I have a C# Winform application (.Net 3.5) which access a MSSQL server using typed DataSet objects.
currently, my whole application is working in one layer, and the client access directly to the DB using those typed DataSet objects.
I want to change my application to client-server model (which will use web-services for communication).
My question is:
How can I pass typed DataSet objects in the web-services?
For example,
I have a table of persons.
And I want my client side to be able to get specific person (using web-service), update its age, and save the change (again using web service).
Is it possible?
Thanks
Since you are using .Net, you should at least check out Entity Framework (the .Net ORM) prior to going with the 3rd party nHibernate. nHibernate might be fine, and might be the way to go, but you should at least compare it to Entity Framework first and have a reason for not using Entity Framework.
You should try something out like Hibernate. Which is an intermediate entity-based mapping between classes and database tables. The queries would be performed on the business side of the application (web service in your case) in the HQL language; which is very similar to regular SQL. I've personally used it multiple times with Java and it can be quite useful. Doing a brief internet search I found "NHibernate" which is a .NET specific version for Hibernate.
For my specific Java application, it is set up such that the GUI is not on the web-service, while basically everything else is. Then using a resource manager, created a "link" which pointed at the business side. All transactions were performed on the web-service, while they were being displayed on the client side.
So to answer your question; yes it is entirely possible.