Factory pattern vs ease-of-use?

Posted by Curtis White on Stack Overflow See other posts from Stack Overflow or by Curtis White
Published on 2010-03-18T15:33:07Z Indexed on 2010/03/18 15:41 UTC
Read the original article Hit count: 503

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

© Stack Overflow or respective owner

Related posts about design-patterns

Related posts about ASP.NET