i want to use asp MVC with the Embedded RavenDB but it looks like that the DB don't react when debug the MVC application (using VS 2010 and IIS 7.5 Express). For Example in a MVC action i write an object an try to read it from the db in the next step, but the object is not found until the next request. For me it looks like the embedded RavenDB can only listen for request if the MVC application is on idle.
If i changed from embedded to the normal Client/Server it works without problems. I would prefer to use the embedded RavenDB. Maybe someone has some experience with this problem?!
The in memory database takes time to do things, so you might be getting stale results.
The nostalequerieslistener from this question should help: RavenDB how to flush?
I had this issue with unit tests, bascially while RavenDB in memory is fast, the small amount of code between inserting and querying for the object is faster.
You can use RavenDB embedded without any disadvantages, except that your application startup will take a little longer, when you create the EmbeddableDocumentStore, but nothing to worry about.
The only thing that you should keep in mind is that while you can seemlessly switch from embedded to client/server, there are (very few) cases where you can't go the other way without modifying your code. For example, the lazy-features aren't available in the embedded session because just don't make sense there.
Easily you can integrate. this might help.
http://msdn.microsoft.com/en-us/magazine/hh547101.aspx
Please mark as answer if solved your issue.
RavenDB implement the Unit Of Work pattern. Do you call SaveChanges on the document session when you are done?
Yep.
Check this post for a complete sample using best practices:
RavenDB, UnitOfWork and MVC - revisited
Related
I'm a .Net desktop applications developer trying to switch to ASP.Net MVC (3 or 4 doesn't matter). We have a .Net library which notifies any GUI you want to put on this assembly by Property Changed Events (or any other custom event we deemed necessary for that matter).
This might not even be a relevant question, because perhaps it's done totally different in ASP.Net MVC, but how do you update your View in the browser on your client after receiving a Property Changed Event from an assembly on your server? We generate these events ourselves by the way. The assemblies are our own.
I've read about Partial Views, but I need to look into that. Whatever I came across seemed so cumbersome. Because it's really straight forward and simple in desktop development. So I'm starting to wonder if Property Changed Events are the way to go when developing for the web.
Thoughts? Links? Sources? I'm interested.
p.s.: See tags for a further understanding of what I'm going for.
HTTP world is entirely different
you request something from the server(Asp.Net MVC) and you get a response back from the server.
there is no way in which the server can contact the user back** as the asp.net server wouldnt keep anything in memory after the response
so here you are wrong in 2 aspects
1. property changes - because after the response there is nothing in the memory of the server there are no models(Objects) so there is nothing whoz property is actually changing
2. even if u maintaining something static if that changes there is no way for you to contact the client back
**there are some frameworks available that allow you to contact the client back and they do this by sockets or comet
You need to move away from the Event-driven thinking of desktop (and WebForms for that matter)-development.
MVC is a designpattern for separation of concerns, and no tightly bound events will exist, unless you do some hack-ish work of your own.
You can, however, accomplish this by using frameworks like SignalR that rely on Javascript and open connections, but the notion of events is not present in MVC.
I'm using SubSonic 3.0 (SimpleRepository) to handle database access in my ASP.NET MVC 1.0 application.
It would be nice to handle a transaction for every web request, committing if everything went smooth and rolling back in case of exception. Is this possible? If so, how?
I know this topic has been discussed many times, but I just couldn't find a satisfactory answer. I have built my own solution (create a TransactionScope in the controller, then commit/rollback in OnActionExecuted), but it turns out to be very unreliable.
The link http://ayende.com/Blog/archive/2011/04/12/refactoring-toward-frictionless-amp-odorless-code-what-about-transactions.aspx applies to NHibernate but i am quite sure you can use it as well. Basically it talks about creating custom action filter . It is also true that it does it action-wide not request wide.
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that
I've not spent much time in the last 3-4 years doing much browser development. So I'm a little behind the times in this area. I'm curious if ASP.NET MVC makes developing complex browser based screens/forms any easier? In the past, the thing I hated most about developer browser apps was hard tedious it was creating screens/forms.
Without pointing out the obvious, you are still working with HTML/CSS and all of the inherent limitations that come with that.
MVC really just provides a more controlled method of passing data around your app. In that respect it's easier to manage data, but it's still being rendered in HTML/CSS.
I haven't built a massive application on the scale of SO, but in my small apps, it still comes down to HTML/CSS.
The MVC 2.0 adds a whole bunch of stuff that makes building forms easier. For example take a look at EditorFor and DisplayFor.
http://davidhayden.com/blog/dave/archive/2009/08/21/HtmlEditorForScaffoldColumnAttribute.aspx
MVC 2.0 also brings form validation using code annotation. You decorate your model properties with attributes from the System.ComponentModel.DataAnnotations namespace and that is uses to build validation rules.
None of this makes it quite as "easy" as WebForms to build forms, but then you don't get stuck with all the old WebForms baggage either.
uh it was a little too easy before with webforms. you're not gonna like that aspect of MVC much...
It's more on the server side where the whole MVC side of it comes into play. Personally I find it simpler when creating AJAX intensive UI's, as hooking up actions to a javascript call seems a bit simpler, but in general, web UI development is what it is.
As an aside - if you don't like creating web UIs (and it's not everybody's cup of tea) - can you structure your team so that you're doing more of the server side code and get a UI developer to run up the front end stuff?
In my opinion it is a lot easier. For one thing we have much better client side javascript frameworks that helps a lot. And with asp.net mvc you don't have to worry about annoying server controls, you will instead have complete control of the html and javascript.
As above, nothing has changed. You still create HTML and CSS, the biggest gain is in using Javascript and Ajax to improve user experiance.
This is very subjective based on your personal experience and what exactly you mean by "complex browser based forms".
If you've been behind in web dev the last few years, then regardless of what route you take, you have some core HTML/CSS/JS stuff to catch up on because that ultimately where the UI gets worked.
I've got a pretty simple site (around 8 pages) with only one way page containing any significant codebehind, and I'd like to try learning MVC, using it as the test.
Is it best to start a new MVC Web App from scratch and cut-and-paste the HTML in, or will it be easier to retool the existing files.
Basically, what am I in for? What's it gonna take to get my Web Forms app into the MVC model? What approach should I take? Create the default MVC web app and start cutting-and-pasting? Add the appropriate namespaces and learn to setup the MVC structure myself?
Unlike tvanfosson, I think you will actually learn more about MVC by trying to translate your existing application. You'll learn which assemblies to add, you'll work out how to associate the right http handlers, you'll learn what the correct web.config settings are, and you'll know which dependencies to remove from your web application to get it to work.
To be honest, it will feel harder doing it this way and be a little more frustrating, but at the end of the process you will know a hell of a lot more than just starting a new one from scratch. Good luck with it.
You'll want to start from a project template in a new project. Transfer your markup to your new views as needed, although it's more likely that you'll just be using the old site as a design template than actually reusing code. You'll find that MVC is much different than WebForms.
I don't think retooling the existing Web Forms application is the best approach (or even feasible). As you will surely discover, the differences between Web Forms and MVC are quite big. So, starting from scratch (although you can recycle the html) will most likely be the better approach and the best way to learn as much as possible about MVC.