The factory pattern is very useful whenever you think you might end up with
a change in implementation. This can be due to different clients, different
projects, etc. That part is fine.

I do not see the sense in the User object as it is, however. If you are
creating an object that gets a user, okay, but I would call it something
other than User, lest it be confused with the actual user object. If what I
am seeing here is the actual User object, I am against the implementation,
as the User object should be a data object, with little or no behavior.

public class User
{
   public string UserName;
   public string FirstName;
   public string LastName;
}

etc.

I would then create some form of collection. Perhaps something like:

public class UserCollection : List<User>
{
}

You can then create a class that creates Users or UserCollections. That
class may be a factory, if there are different types of users, or you might
use a factory to instantiate that class. Both are acceptable patterns. I
would not name this class User, however, as it leads to potential name
clashes.

In general, I do not like objects that fill themselves. While this can be
very useful for lazy loading, you generally end up hammering the database to
fill thousands of objects, which counteracts the one of the primary reasons
for lazy loading (reducing database hits).

Hope this helps.

BTW, while I am not completely sold on their architecture, dofactory.com has
a reference architecture that shows the use of patterns. It does show how to
use the patterns, which is nice, although I would have to code gen the
boilerplate code in their implementation if I were heading that route (to
not do so means you have a more complex architecture for no reason, IMO).

*************************************************