Tag: <span>ASP.NET</span>

I had previously struggled to work out how to deal with injected dependencies that required some data. For example, if you are injecting a mail service, it is going to need the server settings. That’s fine when the service is a class in your own project, but when you want to wrap it up into a reusable Nuget package, it doesn’t work quite so easily.

I finally discovered how easy it is to inject the service with the required settings, so blogged about it before I forgot!

Accessing Google Drive from an ASP.NET application looked easy until I tried it, and discovered that pretty much all the information out there is either misleading or plain wrong.

This blog post explains the three approaches I tried, and why the first two didn’t work. There are also plenty of links to the only reliable source of information I could find.

One of my first posts on this blog was about the problem of using anonymous types when you want to send the data outside of your current class. At the time, the only way I knew to solve this was to create a simple class that had the structure of the anonymous type, and create one of these instead of the anonymous type. I do this regularly, although I have taken to naming such classes CustomerOverview, OrderOverview, etc, instead of CustomerTmp as I did in that blog post, as they aren’t really temporary classes at all, they are slim, flattened overviews of the class.

This approach works well, but it can have its downsides. One, as mentioned in that post, is that it is easy to end up with a proliferation of classes, many of which may only be used in one location in the code. If the classes represent lightweight views of entities in the model (such as the two examples shown above), then I don’t worry about this, as it is clear what they represent, and it’s fairly certain that I’ll end up using them somewhere else at some point.

As the non-existent avid reader of this blog will know, I’m far more interested in learning new technologies than I probably should be, given the limited amount of time I have to learn them properly! With that in mind, I shouldn’t be looking at yet another, but this one does have a very immediate benefit (honest).

I have been an ASP.NET developer for quite a number of years, and can knock out a complex web site fairly quickly. However, as with most of my other programming until recently, this has always been along the “throw it all in the code-behind” anti-pattern. I’ve come a long way in the last six months or so, and am now very comfortable using MVVM in WPF, and separating out my code into logical classes as all the Good Programmers do.

Logically therefore, my web site development should follow the same lines. I read up on both MVC and MVP, and came to the conclusion that as an experienced ASP.NET developer, MVP made a lot more sense to me. I couldn’t honestly see any technical benefit of one over the other, mainly as the MVC proponents seem to raise the same old “webforms are evil” arguments, without any real justification (to me at least, they obviously feel justified). My own feeling was that MVP wins out because it completely isolates the view from any action, meaning that the view is as dumb as it can get, which makes unit testing a doddle. I was won over towards the Passive View version of MVP, as this has even less code in the view than the other flavours.

This is not to say there’s anything wrong with MVC, just that I feel more comfortable with MVP.

This post details my initial exploration of WebFormsMvp.