Comments on: A 3-tier model http://devinstance.wordpress.com/2006/08/19/a-3-tier-model/ Life should taste as good as it Thu, 30 Nov 2006 20:00:16 +0000 http://wordpress.com/ hourly 1 By: ceconjr http://devinstance.wordpress.com/2006/08/19/a-3-tier-model/#comment-5 ceconjr Sat, 26 Aug 2006 19:12:38 +0000 http://devinstance.wordpress.com/2006/08/19/a-3-tier-model/#comment-5 Ok, you've got a point. However, I think that if "ease of migration to different persistence types" was a requirement, I would go with the adoption of a good persistence service implementation like NHibernate (http://www.hibernate.org/343.html). About "data access" being a subject, I do not agree with it (that's just my opinion). We must remember that what matter is not really the number of subjects at all, but the cohesion of a class. As we can define cohesion as the degree of relatedness of the members in a class, I think that a class with a hundred methods that contains dynamic SQL code is not dealing with one subject called "data access", but maybe with a hundred subjects, each one related to the class that uses the method. I'll tell you why: when you write a method in this class (the class that contains all the SQL statements), you will have a code snippet that builds a SQL statement using dynamic SQL. What is the MOST important subject here? The "data access" represented by the construction of the SQL statement or WHAT the SQL statement really do (eg: retrieves a user from database)? I stay with the last one. :) Ok, you’ve got a point.

However, I think that if “ease of migration to different persistence types” was a requirement, I would go with the adoption of a good persistence service implementation like NHibernate (http://www.hibernate.org/343.html).

About “data access” being a subject, I do not agree with it (that’s just my opinion). We must remember that what matter is not really the number of subjects at all, but the cohesion of a class. As we can define cohesion as the degree of relatedness of the members in a class, I think that a class with a hundred methods that contains dynamic SQL code is not dealing with one subject called “data access”, but maybe with a hundred subjects, each one related to the class that uses the method. I’ll tell you why: when you write a method in this class (the class that contains all the SQL statements), you will have a code snippet that builds a SQL statement using dynamic SQL. What is the MOST important subject here? The “data access” represented by the construction of the SQL statement or WHAT the SQL statement really do (eg: retrieves a user from database)? I stay with the last one. :)

]]> By: Igor Ramadas http://devinstance.wordpress.com/2006/08/19/a-3-tier-model/#comment-4 Igor Ramadas Mon, 21 Aug 2006 14:08:13 +0000 http://devinstance.wordpress.com/2006/08/19/a-3-tier-model/#comment-4 I would go with the first option, putting all the SQL statements together. If you need to support a new database or repository, that isn't SQL compliant, you'll have to change all your business classes. Putting them together (all code related to data access on one or more dedicated classes), you could create a base class, that has common statements, and create inherited classes with the special modifications for each database. And you could assume that "data access" is a subject, too :-) I would go with the first option, putting all the SQL statements together. If you need to support a new database or repository, that isn’t SQL compliant, you’ll have to change all your business classes. Putting them together (all code related to data access on one or more dedicated classes), you could create a base class, that has common statements, and create inherited classes with the special modifications for each database.

And you could assume that “data access” is a subject, too :-)

]]>