Factory pattern vs ease-of-use?
- by Curtis White
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 and 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
