The Franciscan Report

I've found this template to be very useful for codegen TDD classes for me.

http://blogs.ipona.com/dan/archive/2007/01/02/SimpleTDDVisualStudioTemplates.aspx

Jay Fields Thoughts: Ruby Form Template Method Using Extend

One of Ruby's feature is the introduction of 'mixin' as demonstrated by Jay's article.

I have a mix feeling about using this feature (no pun intended). To me mixin sounds too close to global function as popularized by language such as C++.

In C++ you can use this "global" function in your class with the right syntax and inclusion. Obviously one would argue what's so bad about that. In the beginning if you have small codebase maybe the drawback is not as obvious, but maintaining this type of code years from now could be hassle in my opinion.

I guess what I'm trying to say things could go out of hand quickly by incorporating this practice.

Suzanne Cook's .NET CLR Notes : New Assembly, Old .NET (and Vice-Versa)

To load the assembly compiled using the previous version of .Net framework such as 1.1, or lower, from a .Net 2.0, you don't have to do any extra effort.

However, things are not the same the other way around, to be able to load a .Net 2.0 assembly from a previous version of .Net you have to add this into your App.config

 
<startup> 
    <supportedRuntime version="v2.0.50727" /> 
    <supportedRuntime version="v2.0.50215" /> 
    <supportedRuntime version="v2.0.40607" /> 
    <supportedRuntime version="v1.1.4322" /> 
    <supportedRuntime version="v1.0.3705" /> 
    <requiredRuntime version="v1.0.3705" /> 
</startup> 

This will allows such case, assuming you have the required version of .Net and the supported runtime version of .net 2.0

Enterprise applications usually use some type of framework to support their underlying applications. Framework can vary from a simple reusable components such as a Math library to a more complex solution such as a mechanims to handle Messaging, Security, etc. Some of the more complex framework requires access to external data storages such as database or a queue, etc.

There are two options on how applications code deploy with this framework's external resouces. One solution is to share the framework's resources amongts all applications, thus data specific to those applications will be stored in the same storages/tables.

The other solution is to store data specific to the application into its own database domain, thus creating a physical boundaries between different applications.

There are pros and cons of both approaches which I will discuss as follows;

The benefits of using the same physical storage for all data are:
- Easy to implement
- Development/Support teams will only have to look at one place to find the data.
- Easy to maintain from the sense where update to data schema will only need to be applied in limited places.

The disadvantages of such solution are:
- Data from different applications are tighly located in the same place.
- No way to protect the integrity of the data of other applications, since different team could potentially affect other team/application data.
- Depends on certain situation/application behavior, there could be performance impact since all applications will be using the same data storage.

The benefit of using segregated data storage:
- No need to worry about affecting other application data, when doing updates/modification to the tables
- If security is a concern, using database to enforce sensitive data between applications is easier to implement.
- No data violation could happen, in a case where some record could have the same values but different meanings, but if the data are stored in the same table, there could be some constraint violations.

The disadvantages of this approach:
- More work for support team, when they have to maintain all applications, thus tools need to be created to leverage this problem.
- Upgrade of data schema need to be applied to more places, but depends on how you implement the schema changes this could work for the benefit of the applications that couldn't afford to have the update yet.

#region my rant

Microsoft introduces a keyword #region ... #endregion that supposedly can be used to organize "like" codes into itsown region.

However, lately I have been encountering that it's also used as a somewhat of an excuse to have big classes. Somehow the use of #region makes it a little tolerable to have big classes.

I don't know if this is what Microsoft intends or not, but it's clearly not an appropriate solution to say the least.

The problem with big classes not only because it's not pretty to our eyesight, but there are some other basic problems with them:
1. Big classes are usually hard to test.
2. Big classes are usually error prone, because regardless of how we divide it up in regions, we still have to understand details of the class, and most humans usually comprehend things as smaller chunks better than one large chunk.
3. The use of region itself should have triggered the fact that the class might have low cohesiveness, thus they could be broken up to smaller classes.

The problems with region are:
1. It's another thing that we have to maintain to make sure things in the region are all "related", I have seen many times, that region starts out well but become "stink" over time.
2. Who's deciding what region to create, which code should go to which region, etc. This is left to each developer interpretation, should we have code review for the region ;-)

#endregion my rant

Ways to prevent SQL Injection Attacks

A few ways to avoid SQL Injection attacks.

In .Net

Instead of

using( SqlConnection con = (acquire connection) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE name = '" + userName + "'", con) ) {
using( SqlDataReader rdr = cmd.ExecuteReader() ){
...
}
}
}


Use the following

using( SqlConnection con = (acquire connection) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE name = @userName", con) ) {

cmd.Parameters.Add("@userName", userName);

using( SqlDataReader rdr = cmd.ExecuteReader() ){
...
}
}
}

In Java.

Instead of

Connection con = (acquire Connection)
Statement stmt = con.createStatement();
ResultSet rset = stmt.executeQuery("SELECT * FROM users WHERE name = '" + userName + "';");


Use the following

Connection con = (acquire Connection)
PreparedStatement pstmt = con.prepareStatement("SELECT * FROM users WHERE name = ?");
pstmt.setString(1, userName);
ResultSet rset = pstmt.executeQuery();

Data Driven Design is generated based on the need to provide users of the system with a set of data.

The common flow of the system will be as follows;
1. A data access object or a business entity object will retrieve the particular data from a database either through stored procedures or dynamic sql statements.
2. The resulting query result will then be mapped to a collection of data objects (usually an anemic model, ie. model with data only, no behavior) representing the information requested by the user.
3. Logics can be embedded to the business entity object (usually contain just behavior with no data member) or the data access object if necessary to act on the data object.
4. This data object will then be passed along to the user to be displayed in the presentation tier. If it needs to cross multiple physical tiers, then this data object is usually called a Data Transfer Object.
5. If the user can resubmit the data back to the server, then the aforementioned business entity object or the data access object can be used to validate user entries.

Benefits of this approach are:
1. It's a more procedural approach in software development, thus doesn't require deep domain expertise.
2. It's easier to implement since data objects are created based on user requirements.

Disadvantages of this approach are:
1. Business logics could be scattered around the system, thus could potentially create accidental duplications (root of all evil).
2. No ubiquitous language and understanding between development team and the business folks, since nobody speaks in term of the actual business domain.
3. No logical boundary exists between inter-related objects, thus could potentially lead to a highly coupled systems.
4. Most of the cases the data objects will be closely mapped to tables in the database, thus it might not take advantages of what Object Oriented Design principles give, ie. polymorphism, inheritance, composition, etc.

Compare this approach to a Domain Driven approach which value system as a set of domain objects and how they are inter-related with each other, which can be defined/contained within their own boundary.