Persistent Object Management in less than 300 Lines of Code

public class Person : PersistentDataObject
{

	public Person() : base("Person", "PersonId") { }
	public Person(int id) : this()
	{
		Load(id);
		address = new Address(AddressId);
	}
	
	private AddressId { get { Get("AddressId"); } }
	
	private Address address;
	public Address Address { get { return address; } }
}

public class Person : PersistentDataObject
{

	public Person() : base("Person", "PersonId") { }
	public Person(int id) : this()	{ Load(id);	}
	
	private AddressId { get { Get("AddressId"); } }
	
	private Address address;
	public Address Address 
	{
		get
		{ 
			if(address == null)
				address = new Address(AddressId);
			return address;
		} 
	}
}

<asp:GridView runat="server" ID="GvPeople" AutoGenerateColumns="false">
  <Columns>
    <asp:TemplateField>
      <ItemTemplate>
        <%#Eval("FirstName") + " " + Eval("LastName")%>
      </ItemTemplate>
    </asp:TemplateField>
    <asp:BoundField DataField="DateOfBirth" HeaderText="Date of Birth"
      DataFormatString="{0}" HtmlEncode="false" />
    <asp:BoundField DataField="LuckyNumber" HeaderText="Lucky Number" />
  </Columns>
 </asp:GridView>

felipedr wrote:

Person person = new Person();
person.FirstName = "Nick";

Whats the people.ID in this context? After insert a record, I need to save a picture, per example. How save the file as "ID + _picture.jpg"?

felipedr wrote:

In my persistence object, I create a method to reload the record after the Insert, reloading the last record inserted as:

Select(String.Format("{0} in (select ident_current('{1}'))", primaryKeyFields[0], nameTable));

Think about this, ok?!

string sql = "SET NOCOUNT ON;"
           + "INSERT "+tableName+" ("+fieldList+")"
           + " VALUES ("+valueList+");"
           + " SELECT SCOPE_IDENTITY()”
           + “ AS InsertionId;";
sc.CommandText = sql;
idValue = Convert.ToInt16(DatabaseAccessor.ExecuteScalar(sc));

felipedr wrote:

And, you can create new "LOAD" methods to increase you class and create a code more fast, adding:

public void Select(string where)
public void Select(string where, string orderby)
public void Select(string campos, string where, string orderby)

private int AddressId
{
  get{return Get("AddressId");}
  set{Set("AddressId", value);}
}
private Address address;
public Address Address
{
  get
  {
    //Use lazy evaluation
    if(address == null)
    {
      //If the Person hasn’t yet been inserted
      //into the database
      if(Id == -1)
        Address = new Address();
      else
        Address = new Address(AddressId);
    }
    return address;
  }
}

protected override void Save()
{
  Address.Save();
  //If we're inserting we'll need the address id
  AddressId = Address.Id;

  base.Save();
}

protected override void Save()
{
  DatabaseAccessor.BeginTransation();
  Try
  {
    Address.Save();
    //If we’re inserting we’ll need the address id
    AddressId = Address.Id;

    base.Save();
    
    DatabaseAccessor.CommitTransation();

  }
  catch(Exception e)
  {
    DatabaseAccessor.RollbackTransation();
  }
}

reinux wrote:

Not to beat a dead horse or anything, but I would have been less inclined to question the security of your code had you explained in the article or code why you had a dummy connection string with a dummy password, which you later explained that you expect none of your readers to follow such example. Think of the beginners who might have gone ahead and done the same thing!

reinux wrote:

It'd be a better idea to let the user set the SqlConnection object. DatabaseAccessor is probably unnecessary too; it'd be a better idea to put all that functionality inside PersistentDataObject itself.

Nick Higgs wrote:

Are you suggesting that impressionable beginners who see that I have posted code containing a connection and string may "follow my example" by posting code containing a connection string that could be used to connect to a database via the internet? Well, I guess it could happen, but it's not a flaw in the code its self though is it? Hard coding a connection string is considered bad practice because it doesn't promote portability, that is, you can't swap to another database without recompiling the code. It doesn’t make the application any less secure.

Nick Higgs wrote:

DatabaseAccessor contains functionality that is likely to be needed by classes other than PersistentDataObject, so it makes complete sense to encapsulate it in a separate class. Even if this wasn't the case, it's good practice for a class not to have disparate responsibilities.

Nick Higgs wrote:

I included DatabaseAccessor for completeness, but I would expect that most C# developers will already have a similar class that they use most of the time.

sqlCommand.Connection = SqlConnection;
SqlConnection.Open();
using (SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(sqlCommand))
   sqlDataAdapter.Fill(ds);

SqlConnection.Open();
sc.Connection = SqlConnection;
obj = sc.ExecuteScalar();

SqlConnection.Open();
sqlCommand.Connection = SqlConnection;
iRowsAffected = sqlCommand.ExecuteNonQuery();

reinux wrote:

You don't want to expose anything from your class library that doesn't immediate accomplish what the library is designed for...

reinux wrote:

...PersistentDataObject is reliant on DatabaseAccessor ... which would render PersistentDataObject unusable without modification.

Nick Higgs wrote:

The only reason I provided DatabaseAccessor was so the code would work without modification, and it does. My point was that many developers would want to switch it for a similar class that they already use.

As you started this thread to point out security flaws (that, as it turns out, don't exist) and you're now focusing on the division and exposure of responsibilities, I think you're nit picking. The criticisms you've made are subjective and don't indicate any bad practice in my code; therefore, I'm going to consider this thread concluded.

Nick Higgs wrote:

I'm not sure what your point is, surely you're not suggesting that a stored procedure based business tier is "procedureless". My point was that a set of stored procedures have no structure connecting them or defining them relative to each other, which means they don't assist much when trying to maintain data integrity.

Nick Higgs wrote:

However I would question the suitability of stored procedures as a technology for the business tier. It seems odd that you're advocating separating business and application logic by tying business and data logic closer together.

reinux wrote:

Why?

reinux wrote:

Data integrity and business logic should be done as close to the data as possible.