Factory pattern vs ease-of-use?

Background, I am extending the ASP.NET Membership with custom classes and extra tables.

The ASP.NET MembershipUser has a protected constructor and a public method to read the data from the database. I have extended the database structure with custom tables and associated classes.

Instead of using a static method to create a new member, as in the original API: I allow the code to instantiate a simple object and fill the data because there are several entities.

Original Pattern #1 Protected constructor

> static CreateUser(string mydata, string, mydata, ...) 
> User.Data = mydata;
> User.Update()

My Preferred Pattern #2 Public constructor

> newUser = new MembershipUser();
> newUser.data = ...
> newUser.ComplextObject.Data = ...
> newUser.Insert() 
> newUser.Load(string key)

I find pattern #2 to be easier an开发者_如何转开发d more natural to use. But method #1 is more atomic and ensured to contain proper data.

I'd like to hear any opinions on pros/cons. The problem in my mind is that I prefer a simple CRUD/object but I am, also, trying to utilize the underlying API. These methods do not match completely. For example, the API has methods, like UnlockUser() and a readonly property for the IsLockedOut.

I can see there are a few possibilities.

Option #1 Have the object save/load itself but require a private constructor.

Option #2 Have the object save/load itself but let it have a public constructor

Option #3 One is to create a POCO/simple CRUD object and then have static methods for updating the database. ..............

Option #1 Benefits: Multi-threading safety "atomic", object integrity Detriments: Difficult to use -> passing lots of data, possibly require updating after creating which would require wrapping in a transaction in some cases so it seems messy

Option #2 Benefits: Easy to use, easy way to organize the transactions Downside: Object may or may not be set appropriately

I prefer your option #2 better. I strongly prefer objects with default constructors. You say you like #1 because it forces you to put the data in but in reality, you should have validations for that anyways, right? So if you have validations, why not just rely on those? If you don't have them, then put them in! (Admittedly, one of the major reasons I prefer default constructors is for serialization, and it tends to be easier to test.)

Just my $0.02 worth.