Karl Seguin - All Comments

re: Get SOLID: Single Responsibility Principle

Colin Jack — Mon, 05 Jan 2009 12:42:48 GMT

"SRP states that a class should have one and only one responsibility."

I think the better definition, and the one I've read, is reason for change. Responsibility is way too vague for my liking.

re: new Repository().DoMagic()

Remi Despres-Smyth — Mon, 05 Jan 2009 12:41:16 GMT

Karl: Thanks for your thoughts - I really enjoyed the article.

Regards,

Remi.

re: Get SOLID: Single Responsibility Principle

Dave Schinkel — Mon, 05 Jan 2009 04:43:02 GMT

>>>Well, I have a further problem with the semantics of this... what is a purpose? I can easily state a class' 'purpose' as been anything at any level of detail or abstract.

start with commenting your class to give it a purpose. When a developer looks at a class, it's purpose should be commented on at the top as a FIRST step for one thing

#.think.in infoDose #14 (22nd Dec - 2nd Jan)

#.think.in — Sun, 04 Jan 2009 21:49:03 GMT

#.think.in infoDose #14 (22nd Dec - 2nd Jan)

re: new Repository().DoMagic()

karl — Sun, 04 Jan 2009 03:36:21 GMT

Remi:

I think your approach is better for larger systems - I happened to be working on something with only a few domain objects so that's the mindset I was in.

Keeping references to repositories within domain entities can cause all sorts of nasty bugs to creep up - largely causes by caching and such. I can't remember the details, but I remember spending a few days tracking down an obscure bug which ended up being caused by entities holding on to references to stale repositories. I think it's simply to simply use a DI framework and ask for the repository whenever its needed. This works well in .NET since the scope of a unit of work is generally tied to an individual request (it's why the Session-per-request model for Nhibernate works so well too). Not sure how I'd go about doing it for non-web apps though.

Karl

re: new Repository().DoMagic()

karl — Sun, 04 Jan 2009 03:36:20 GMT

Remi:

I think your approach is better for larger systems - I happened to be working on something with only a few domain objects so that's the mindset I was in.

Karl

Compressing JS files as part of your build process

DotNetShoutout — Sun, 04 Jan 2009 00:19:38 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

Compressing JS files as part of your build process

DotNetShoutout — Sun, 04 Jan 2009 00:19:14 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: new Repository().DoMagic()

Remi Despres-Smyth — Sat, 03 Jan 2009 17:07:51 GMT

Karl, I notice that your repository contains an instance of the domain class it represents. In my case, when I've used repositories - even generic ones - I've typically set them up using a repository instance per domain aggregate class (passing the instance in by param), and not a repository per domain aggregate instance (which I believe is the implication here).

I would be interested in hearing your thoughts on the advantages in your approach.

Also, how does the repository get called for a loaded aggregate instance? Who keeps a reference to the repository?

Regards,

Remi.

re: new Repository().DoMagic()

Remi Despres-Smyth — Sat, 03 Jan 2009 17:07:35 GMT

Karl, I notice that your repository contains an instance of the domain class it represents. In my case, when I've used repositories - even generic ones - I've typically set them up using a repository instance per domain aggregate class, and not a repository per domain aggregate instance (which I believe is the implication here).

I would be interested in hearing your thoughts on the advantages in your approach.

Also, how does the repository get called for a loaded aggregate instance? Who keeps a reference to the repository?

Regards,

Remi.

re: HttpHandlers – Learn Them. Use Them.

DevMan — Fri, 02 Jan 2009 22:52:28 GMT

Still pretty foggy on the advantages and uses of an http handler.

I'd say this article falls into the "bad tech writers are squarely to blame" catagorie.

You've jumped from hello world to proprietary binary serialization.

Visual Studio Links #94

Visual Studio Hacks — Wed, 31 Dec 2008 17:41:38 GMT

My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. New in Visual Studio Gallery: Delphi Prism - Delphi programming for .NET in Visual Studio. The Web Developer Tools Team posted an

re: Compressing JS files as part of your build process

Timothy — Wed, 31 Dec 2008 15:25:33 GMT

I'm not much of a fan of JQuery (MooTools all the way! Or at least Prototype...). But, yea, YUICompressor should be used in every project.

In fact, everyone should get the YSlow extension for Firebug to see what can be done to improve performance.

re: Compressing JS files as part of your build process

Peter Mounce — Tue, 30 Dec 2008 23:36:36 GMT

Your Html.IncludeJs registers a single script-block per file? You'll get significantly better performance (both in terms of number of requests going down, and in terms of compression efficiency) if you, in release mode, include one set of javascripts minified and globbed together into a single file. See www.julienlecomte.net/.../13 and compar your approach as now to a one-minified-file approach with Firebug/YSlow.

You can do the one-minified-file approach by changing the helper to add the path to a set (as in, set-semantics list), and then (I'm coming from MonoRail, not MS-MVC) write out the script includes as an after-rendering filter - in debug mode, write out one include per file, linking against the debug copies; in release mode, write out a single include that links against the set of scripts, minified.

Except you can't do that (well, you _can_, but... ;-) ) with a build-time task, because it would need to know all of the possible combinations of script-includes that your app uses. I think in this case if you care enough to be compressing in the first place (ie, you need to scale / want responsive UI), you can probably eat the production-CPU-cycles and be better off doing this at run-time, not build-time.

For interest, there is a most-of-the-way-there patch to MonoRail that creates a ViewComponent that does most of this - it lacks a debug-mode switch, currently. You can see that at support.castleproject.org/.../MR-ISSUE-457.

re: Compressing JS files as part of your build process

Brennan Stehling — Tue, 30 Dec 2008 22:10:26 GMT

Have you seen Packer for .NET?

It provides MSBuild tasks and can compress with Packer or JSMin modes. Recently I got a contribution of CSSMinify to the project so you can compress CSS as well now. You can either do it at build time or use the assembly to do it at runtime.