Tea-Driven Development » asp.net

Use Rsync to Copy Your ASP.NET Website

Matt — Sun, 23 Mar 2008 01:34:29 +0000

If you’ve ever tried to copy the source files from a Visual Studio 2005 ASP.NET solution, especially if you’re using TFS and Resharper, you’ll have probably noticed all great steaming heaps of fluff and nonsense these tools leave all over your hard drive. Not to mention all the built assemblies lurking in your bin/Debug folders.

If you have a unix/linux/apple machine handy, or have at least had the sense to instal cygwin or coLinux on your quaint old PC, then give this a rumble.

Prepare a file with the inclusion / exclusion rules for the files / folders you want to copy. For my solution, it looks like this:

*.cs
**/lib/.
*.csproj
*.sln
*.resx
*.jgp
*.gif
*.gif
*.aspx
*.ashx
*.js
*.ascx
*.config
*.xml
*.txt
*.html
*.htm
*.dbp
*.sql
*/
*

There are a few fascinating points to note about this file:

The lines that begin with a ‘+’ character are include rules.
The second line copies anything in a /lib folder, which is where we keep dependencies in my world
The second-to-last line tells rsync to copy every folder. Without this, the last line would exclude all the folders (rsync works its way through the folder tree recursively) and you’d never get to the files you’d mentioned above. Read that bit again, it’s hard to understand at first, but important.
The last line excludes everything else.

Now fire up your terminal, and invoke the magic of rsync:

rsync -av –exclude-from=files.txt source/Projects/Widgets/ target/Projects/Widgets/

Which means

copy all files (recursively)
write verbose output

And there you have it. Yet more unix joy.

Avoid Spaghetti Execution with the Judicious use of Inline Scripting

Matt — Tue, 30 Oct 2007 08:55:03 +0000

Rob Conery has kicked up a bit of a stink posting about the use of inline scripting in modern ASP.NET apps.

I may post more on this subject when I have time, but I had to just weigh in with my support for disciplined use of this technique, which can save you hundreds of pointless lines of code and execution cycles in a large app if used wisely.

One trick we use is to replace all those silly asp:LinkButton tags with a good ole anchor tag, and a call to a special utility class called LinkBuilder which knows how the site’s URLs hang together, like so:

Cancel

This sort of markup can hardly be acused of being spaghetti code (the LinkBuilder method has a single line inside it), and means that we avoid what you might call ‘spaghetti execution’ when you actually come to spin the thing up.

Think about what a sequence diagram of the equivalent use of an asp:LinkButton with a wired OnClick event would look like. Eugh.

Model-View-Presenter (MVP) Anti-Patterns

Matt — Wed, 13 Jun 2007 19:07:50 +0000

As I work with the MVP / Passive View / Humble View pattern more in ASP.NET, I’m gaining an understanding of some common smells or anti-patterns that can happen when you try to implement this pattern and haven’t quite grokked it yet. Some of these are problems I’ve had to pull out of my own code:

TOO MANY PRESENTERS SPOIL THE BROTH

When you re-use a user-control or even just a view interface on different pages, it’s tempting to re-use a special little presenter inside each of those pages whose sole responsibility is for presenting that usercontrol. If you have two different flavours of page, you might even put the call to the presenter into a BasePage.

This is fine as long as those pages need no other pesenter logic, but there are usually other controls on the page too, and they’ll need to be presented, and before you know it you have two or three or a whole crowd of presenters yelling at different bits of your page, telling them what to do.

Lesson: This is the path of darkness and complexity on the tightrope of your untestable UI layer. Re-use presenter logic by all means, but do it inside the presenter layer, where you can test. Everybody say Ahh… Tests…

Maxim: No more than one presenter to be constructed per page / request.

THE SELF-AWARE VIEW

Within a request / response cycle, only the Page should be aware of the existence of a presenter. The HUMBLE VIEW (implemented in a UserControl) does what it’s told without any knowledge of who is dishing out the instructions. Find this smell by looking for UserControls which construct their own private little presenters, or worse still accept them as properties (usually so that they can do filthy things like call methods on them – see ARROGANT VIEW, below).

ARROGANT VIEW

The arrogant view is not only SELF-AWARE, but has the temerity to imagine that it has the right to give the presenter direct instructions. Thus a presenter can easily be relegated to nothing more that a PROXY MODEL, with logic creeping up into the untestable view layer. Find this smell by looking for presenters which offer public methods. Replace these direct method calls from view->presenter with a more humble OBSERVER PATTERN, where the view raises events containing the relevant information in the EventArgs, and the presenter reacts accordingly (or decides not to, as is its privilege).

PRESENTER BECOMES PROXY MODEL

When you have an ARROGANT VIEW that commits the crime of directly calling methods on a presenter, you start to see the logic in the presenter thin down to the point where it becomes little more than a proxy for the ‘model’ (in classic MVC terminology) or service layer. The whole idea of MVP is to delegate the responsibility of figuring out what to fetch from the service layer and when to fetch it, so that the view just gets on with displaying whatever the presenter decides it should display. When an ARROGANT VIEW gets these kind of notions, logic that belongs in a (testable) presenter is tangled up with display logic in the view, and it’s time to roll up your sleeves and refactor.