SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 36
  1. #1
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    how to best implement model classes

    I know this is a very broad subject but how do you guys implement your model classes?

    Right now I've got one 'uber' Model class (for example, UserModel) which has all the necessary methods/SQL for ANY operation related to users (add a user, delete, change privileges, return a list of users etc).

    The fact it's an 'uber' class makes me suspicious that there's a better way to do things. Probably having a User class and giving it appropriate functionality to deal with single User instances from the database (so the User class represents a single User and has operations only for single user manipulation) and having UserFinder classes to handle getting lists of Users etc. But in some implementations I've seen the User class have all the functionality e.g. for finding multiple Users as well as updating singular Users (so the User object can represent a single user but has operations for listing many?). As I type this I realise it's no better than the 'uber' model class but which do you find is the best approach?

    In code terms:

    Code PHP:
    $model = new UserModel($db);
    $model->findUser(array('id'=>23432));
    $list = $model->findAllUsers();
    $model->updateUser(array('id'=>32432, 'name'=>'Bob'));
     
    //vs
     
    $u = new User($db, array('id'=>2323)); //fetch a user with $id
    $u->name = 'Bob';
    $u->save(); //update single user
     
    $f = new UserFinder($db0:
    $list = $f->findAllUsers();
     
    //vs
     
    $u = new User($db, array('id'=>2323)); //fetch a user with $id
    $u->name = 'Bob';
    $u->save(); //update single user
    $list = $u->findAllUsers();

  2. #2
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I'd say your second example is the best.

    The first is loose, and the object doesn't really know what it represents.
    The third shouldn't be used as the method findAllUsers() doesn't relate to the object.

    The second is an object relating to the database structure, and is tied to a particular row - and cuts down on code too.
    Last edited by Jake Arkinstall; Oct 24, 2008 at 11:38. Reason: Yeah, Old Iron was right... :lol:
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  3. #3
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    I'd say your first example is the best.
    you mean my second example? lol

  4. #4
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I prefer the first example, so that all database logic is kept away from business logic. I generally use domain objects instead of arrays, but that's not always necessary.

    The fact it's an 'uber' class makes me suspicious that there's a better way to do things.
    I wouldn't say that means there's a "better way", more like you need to refactor out another class or two.

  5. #5
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    generally use domain objects instead of arrays, but that's not always necessary.
    could you give a practical example please? i'm new to the concept of domain objects.

    I thought the db stuff should go in one class but it's just becoming a very large class.. at first I didn't think objects should know about where they came from (i.e. a User object shouldn't know about the database which populated it - because the object may not come from a database at all I guess) but I'm not sure whether that's me being too puritanical?

  6. #6
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    could you give a practical example please? i'm new to the concept of domain objects.
    Just a quick example:

    PHP Code:
    $userMapper = new UserMapper ($db);
    $user $userMapper->getById (10);
    echo 
    $user->getName();
    $user->setName ('George');
    $userMapper->save ($user); 
    I thought the db stuff should go in one class but it's just becoming a very large class.. at first I didn't think objects should know about where they came from (i.e. a User object shouldn't know about the database which populated it - because the object may not come from a database at all I guess) but I'm not sure whether that's me being too puritanical?
    Maybe post the class, and we can help you extract out some logic into another class?

  7. #7
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PoEAA says there are essentially three ways to look at your model classes, with each getting progressively further from the database.

    1) Transaction Script - logic is seen as a series of transactions
    2) Table Module - logic is grouped around tables in the database
    3) Domain Model - logic is seen as an object model, database is an afterthought

    Number 3 is obviously the most flexible, but it is also a lot harder to get right. Unfortunately I think we as programmers often equate "most flexible" with "the correct way", so we end up killing a lot of time when we don't necessarily have to.

    There's a lot to be said about a well structured transaction script. For instance, let's say you're developing an e-commerce app. You decide to model the order pipeline as a series of transactions -- order placement, invoicing, shipment, etc. That's a perfectly valid model of the problem you're facing, so why not?

    You end up with a layer supertype for your scripts...

    PHP Code:
    abstract class TransactionScript {
        protected 
    $db;
        function 
    __construct(PDO $db) {
            
    $db->setAttribute(PDO::ATTR_ERRMODEPDO::ERRMODE_EXCEPTION);
            
    $db->setAttribute(PDO::ATTR_AUTOCOMMITfalse);
            
    $db->setAttribute(PDO::ATTR_EMULATE_PREPAREStrue);
            
    $this->db $db;
        }
        function 
    prepare($sql) {
            return 
    $this->db->prepare($sql);
        }
        function 
    lastInsertId() {
            return 
    $this->db->lastInsertId();
        }
        function 
    begin() {
            return 
    $this->db->beginTransaction();
        }
        function 
    rollback() {
            return 
    $this->db->rollBack();
        }
        function 
    commit() {
            return 
    $this->db->commit();
        }
        abstract function 
    exec(DataTransferObject $data);

    And a bunch of these things, one for each step in the pipeline...

    PHP Code:
    class PlaceOrderScript extends TransactionScript {
        function 
    exec(OrderData $order) {
            
    $this->begin();
            try {
                
    $orderId $this->insertOrder($order->customerId);
                foreach (
    $order->lines as $line) {
                    
    $this->insertOrderLine(...);
                }
            } catch (
    Exception $e) {
                
    $this->rollback();
                return 
    false;
            }
            return 
    $this->commit();
        }
        protected function 
    insertOrder($customerId) {
            
    $stmt $this->prepare("INSERT INTO orders (customer_id, status) VALUES (?, 'new')");
            
    $stmt->bindParam(1$customerIdPDO::PARAM_INT);
            
    $stmt->execute();
            return 
    $this->lastInsertId();
        }
        protected function 
    insertOrderLine($orderId$productId$quantity) {
            
    $stmt $this->prepare("INSERT INTO order_details (order_id, product_id, qty) VALUES (?, ?, ?)");
            
    $stmt->bindParam(1$orderIdPDO::PARAM_INT);
            
    $stmt->bindParam(2$productIdPDO::PARAM_INT);
            
    $stmt->bindParam(3$quantityPDO::PARAM_INT);
            
    $stmt->execute();
            return 
    $this->lastInsertId();
        }

    What's so great about that? Well, for starters, everything is right there in the same class. You deal directly in the terms of the database, you don't have to set up any mapping layers, etc. You lose stuff too obviously, but trade offs are part of the game.

    Not saying this is the way you should go of course. Just wanted to emphasize that it's a valid option.

  8. #8
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks allspiritsteve and cuberoot for your answers:

    @allspiritsteve, here is a (work in progress) ForumModel class I have:

    Code PHP:
    <?php
    class ForumModel extends Model {
    	function addForum($data) {}
    	function getForums() {}
    	function addTopic($data) {}
    	function deleteTopic($topicId) {}
    	function getTopics($params) {}
    	function addPost($data) {}
    	function deletePost($id) {}
    	function getPosts($params) {}
    	function getPost($postId) {}
    	function editPost($data) { }
    	function getTopicIdFromPost($postId) {}
    	function getTopicHeader($topicId) {}
    	function getForumHeader($forumId) {}
    }
     
    ?>

    Which is only going to get bigger.. should I break this down into ForumMapper, PostMapper, TopicMapper classes? Or just keep the ForumModel class and make that class use the Post/Topic/ForumMapper classes to get its work done?

    @cuberoot, yes I keep reading about transaction classes and all the good programmers seem to go that route instead of making a ton of flexible classes: personally I have a whole host of interfaces and abstract classes, for example:
    MySQLDatabase extends Database implements iDatabase, iDatasource
    It seems that in practice the experts don't do all this and just go off maybe one interface and one implementation instead of a complex (and mostly abstract) hierarchy.
    But the way you are saying it, every method in my ForumModel above would become its own transaction script? (and thus have its own class) - isn't there a performance hit here?
    What is the advantage of using a transaction for a simple insert query (just inserting one row into the database) over just calling the query?

    Again, thanks for your answers!

  9. #9
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At first I'd probably start with what I put up there, but I'd start moving certain queries into another class as soon as I encountered a need for them elsewhere. These new classes are called table data gateways and they're a good place to put SQL queries. Looking at your code, this is basically what you have.

    Table data gateways gives you structured access to your database rows, but you'll obviously have to represent more complex logic somewhere else. You can do that in a transaction script, a table module, or a domain model. It depends on what you're doing, how much change is anticipated, how much time you have, etc.

    However, in some cases one approach will stand out more than the others. Let's say you have to write a migration script that involves moving data between multiple databases and file systems. You want to make sure the migration succeeds as a whole or gets rolled back to the pre-migration state. The transaction script approach obviously fits this scenario much better than the others.

  10. #10
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cuberoot View Post
    However, in some cases one approach will stand out more than the others.
    Hm, well, there's at least one instance in the wip forum app where transactionality would come in useful, as right now I am inserting a row, attempting to insert another row in a different table (with a foreign key of the previously inserted row) and if this fails the app deletes the previously inserted row.. if I use a transaction as you describe I can just roll back the changes instead of re-deleting. I'll give this way a try.

    One question though:

    Quote Originally Posted by From Wiki
    The Transaction Script Pattern should be used when the application itself does not have much logic, or it does not have much overhead in performance and understanding. As the business logic getting complex, other patterns such as Domain model pattern is a better choice.
    Does this mean the transactional approach is limited in what it does? How 'complex' would an application have to be to justify using a domain model pattern?

  11. #11
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The name of the pattern makes it seem like a transaction script is the only viable option when it comes to using database transactions, but you will actually use transactions in any of the three.

    Transaction scripts are so named because the logic is divided up along the lines of this transaction and that transaction, whereas the other approaches divide the logic up along different lines. The need for transactions remains however, since you have to manage concurrent access to the database no matter what.

    I don't necessarily agree with the blanket statement given in that wiki. A transaction script can contain complex logic without creating any performance issues. The state pattern works well in combination with transaction scripts, so that complexity can be managed fairly well.

    As for when to use a domain model, I think it's hard to prescribe a time to apply it. At least that's the conclusion I've come to after erasing this paragraph 10 times or so. In my own experience, page controllers and transaction scripts are often all you need for a web application.

    I know people talk about front controllers and domain models an awful lot, but I think they're working on problems that called for those things. Chances are they didn't start out with them, but evolved them over time.

    I think this is a good approach. Rather than figuring out how to apply a particular pattern to a problem, you spend some quality time with the problem and wait for applicable patterns to emerge. You might cut to the chase in future projects of course, but that's only because of the foresight granted by experience.

    You can also use different modeling approaches in the same application. For instance, you might use transaction scripts across the board, except for one particular aspect which uses a full blown domain model, such as a resource scheduler or some such thing.

  12. #12
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's been my understanding that Transaction Script actually has performance benefits. In terms of PHP, yes, you may have more classes, but you don't need to instantiate them all for a single transaction. For example, in the Domain Model, you might have a Joke class with methods for retrieving, inserting, updating, and deleting jokes from the database. With Transaction Script, you might break these into individual classes that are about a quarter of the size. (Maybe that's a little optimistic. ) Now, rather than loading one big class, you load one small class, and off you go.

    Another example would be a more complex form of data retrieval. Suppose you have a transaction in which you need to get data from across several tables, manipulating it quite a bit, and comparing the manipulated values. You could do this with Domain Model probably quite a number of ways, but for the sake of argument, let's say you fetch data from each table separately, and handle the manipulations and comparisons in PHP. This might be a job that could be taken care of by one query (albeit pretty complex). In this case, your one class in Transaction Script would let SQL do its thing, and retrieve the data right as you want it. This would probably put a little more strain on the database, but overall should perform better.

  13. #13
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,401
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I think what you written above is PHP.. I think.. Anyways, here's an example of how Java EJB deals with this.

    The class User does not have the method called "save". All it contains is getters/setters for each of the attributes. The way to save is to use DAO (Data Access Object). So in this case, we would create a class called UserDAO to save. The syntax would be like

    UserDAO.beginTransaction();
    User user = new User ("frank");
    UserDAO.save(user); // creates new entry
    UserDAO.commit();

    User frank = UserDAO.findByName("frank");
    frank.setAge(12);
    UserDAO.beginTransaction();
    UserDAO.update(frank); // update the age
    UserDAO.commit();

    List userList = UserDAO.findAll() // retrieves all users

    So, for all DB functionalities you can add it to UserDAO and not mingle w/ User class. To me this makes sense.

  14. #14
    SitePoint Wizard
    Join Date
    Apr 2007
    Posts
    1,401
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    Thanks allspiritsteve and cuberoot for your answers:

    @allspiritsteve, here is a (work in progress) ForumModel class I have:

    Code PHP:
    <?php
    class ForumModel extends Model {
    	function addForum($data) {}
    	function getForums() {}
    	function addTopic($data) {}
    	function deleteTopic($topicId) {}
    	function getTopics($params) {}
    	function addPost($data) {}
    	function deletePost($id) {}
    	function getPosts($params) {}
    	function getPost($postId) {}
    	function editPost($data) { }
    	function getTopicIdFromPost($postId) {}
    	function getTopicHeader($topicId) {}
    	function getForumHeader($forumId) {}
    }
     
    ?>

    Which is only going to get bigger.. should I break this down into ForumMapper, PostMapper, TopicMapper classes? Or just keep the ForumModel class and make that class use the Post/Topic/ForumMapper classes to get its work done?

    @cuberoot, yes I keep reading about transaction classes and all the good programmers seem to go that route instead of making a ton of flexible classes: personally I have a whole host of interfaces and abstract classes, for example:
    MySQLDatabase extends Database implements iDatabase, iDatasource
    It seems that in practice the experts don't do all this and just go off maybe one interface and one implementation instead of a complex (and mostly abstract) hierarchy.
    But the way you are saying it, every method in my ForumModel above would become its own transaction script? (and thus have its own class) - isn't there a performance hit here?
    What is the advantage of using a transaction for a simple insert query (just inserting one row into the database) over just calling the query?

    Again, thanks for your answers!
    Abso****inglutely create seperate class. It just makes it easier down the road.

    As far as transaction performance of hitting 1 row is insignificant... Common mistake of using the transaction is like

    begin transaction
    retrieve a row from database
    do business logic
    more calculation
    more if/then/else
    more stupid stuff
    finally save to db
    end transaction

    In order to optimize performance, only include the code that deals w/ db actions in the transaction and nothing else.
    So the optimize solution would be



    retrieve a row from database
    do business logic
    more calculation
    more if/then/else
    more stupid stuff

    begin transaction
    save to db
    end transaction

  15. #15
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    Code PHP:
    <?php
    class ForumModel extends Model {
    	function addForum($data) {}
    	function getForums() {}
    	function addTopic($data) {}
    	function deleteTopic($topicId) {}
    	function getTopics($params) {}
    	function addPost($data) {}
    	function deletePost($id) {}
    	function getPosts($params) {}
    	function getPost($postId) {}
    	function editPost($data) { }
    	function getTopicIdFromPost($postId) {}
    	function getTopicHeader($topicId) {}
    	function getForumHeader($forumId) {}
    }
     
    ?>
    I would probably go for a design that conformed to DRY principles.

    PHP Code:
    <?php 
     
    abstract class Model
     
    {
       public function 
    __construct($db$scheme){}
       public function 
    create(){}
       public function 
    update(){}
       public function 
    remove(){}
       public function 
    get(){}
       public function 
    set(){}
     }

     class 
    Forum extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }

     class 
    Topic extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }

     class 
    Post extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }
    ?>

  16. #16
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    5 Thread(s)
    Separate entities deserve separate classes. Topics,forums and posts should be different classes. Therefore, I'm inclined to agree with imaginethis.

    sg707 wrote:
    I think what you written above is PHP.. I think.. Anyways, here's an example of how Java EJB deals with this.

    The class User does not have the method called "save". All it contains is getters/setters for each of the attributes. The way to save is to use DAO (Data Access Object). So in this case, we would create a class called UserDAO to save. The syntax would be like

    UserDAO.beginTransaction();
    User user = new User ("frank");
    UserDAO.save(user); // creates new entry
    UserDAO.commit();

    User frank = UserDAO.findByName("frank");
    frank.setAge(12);
    UserDAO.beginTransaction();
    UserDAO.update(frank); // update the age
    UserDAO.commit();

    List userList = UserDAO.findAll() // retrieves all users

    So, for all DB functionalities you can add it to UserDAO and not mingle w/ User class. To me this makes sense.
    Seems logical, but the UserDAO is dependent on the User.

  17. #17
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have to agree with imaginethis here.

    I don't know why you guys like creating these huge classes with all the functionality hard-coded into the specific class. Just go with a more generic abstract class and extend it for each table. Much less work + a standard interface. Keep it DRY, guys. No use in coding the same tedious SQL over and over.

  18. #18
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    Seems logical, but the UserDAO is dependent on the User.
    What's wrong with that? It's the UserDAO's job to map between the db and the User object. If it didn't know about the User object, how could it do its job?

  19. #19
    SitePoint Addict
    Join Date
    Dec 2007
    Posts
    348
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    I would probably go for a design that conformed to DRY principles.

    PHP Code:
    <?php 
     
    abstract class Model
     
    {
       public function 
    __construct($db$scheme){}
       public function 
    create(){}
       public function 
    update(){}
       public function 
    remove(){}
       public function 
    get(){}
       public function 
    set(){}
     }

     class 
    Forum extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }

     class 
    Topic extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }

     class 
    Post extends Model
     
    {
        public function 
    __construct($db$scheme null)
        {
        
    parent::__cunstruct($db, array(/* tables, columns, etc.. */)))
        }
     }
    ?>
    I assume this is instead of having Dao/Mapper/Finder classes since we're putting db functionality directly in model classes? Sort of like domain objects, or is this actually an example of domain objects?

  20. #20
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been building database applications with PHP for years, and my approach is as follows:

    (1) I use the 3 Tier Architecture which separates the application into a Presentation (UI) layer, Business layer and Data Access layer.
    (2) The Business layer has a separate class for each table in the database.
    (3) The Data Access layer is a single object which handles all communication with the database.

    Each database table class is very small as it inherits a large amount of common code from an abstract table class. This class has standard methods such as getData(), insertRecord(), updateRecord() and deleteRecord() which handle any validation before communicating with the Data Access Object (DAO). It is the DAO which constructs the final SQL query and executes it against the physical database.

    My presentation layer contains numerous page controllers which deal with the HTTP requests and return the responses. Each controller communicates with one or more table objects using the aforementioned getData(), insertRecord(), updateRecord() and deleteRecord() methods. This method of polymorphism enables a controller to be used on any table in the database, which means that I have a small number of standard controllers which are highly reusable.

    I do not bother with getters and setters for individual fields as what goes in is an array (typically the $_POST array) and what comes out is an array. Each table object can therefore deal with any number of database rows.

    The getData() method has a single argument, a WHERE string, which enables me to deal with an infinite number of queries with a single mehod. I do not waste my time with separate methods for findByKey(), findByName() et cetera.

    The DAO may be instantiated from either a MySQL class, a PostgreSQL class or an Oracle class. This enables me to switch from one DBMS to another by changing a single variable.

    My design method of choice is TOD (Table Oriented Design) which means that I design my database first, then build my software components around the database structure. This means that I do not have any impedence mismatches which require the use of that abomination called an ORM.

    I refuse to use OOD (Object Oriented Design) in which the software components are designed first and the database is thrown in as an afterthought. That is backwards thinking as far as I am concerned.

  21. #21
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by old_iron View Post
    I assume this is instead of having Dao/Mapper/Finder classes since we're putting db functionality directly in model classes? Sort of like domain objects, or is this actually an example of domain objects?
    I personally would make each of those subclasses a DAO, and keep db code out of the class entirely.

    This example keeps it all together though, which is more of an ActiveRecord. Considering a domain object is only supposed to have data and behavior that make sense in the domain language, I would not consider them domain objects.

    This approach links objects directly to tables 1:1, and that is not always desired.

  22. #22
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Sutton, Surrey
    Posts
    259
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    Considering a domain object is only supposed to have data and behavior that make sense in the domain language, I would not consider them domain objects.
    What you call a "domain object" I call a Business layer object, and each object in the Business layer is supposed to handle the data and behaviour for a business entity. It does not communicate with the database - that is handled by the DAO in the data access layer (and no ORM whatsoever). It does not communicate with the user - that is handled by the presentation layer.

    As for a Domain Specific Language (DSL) I use SQL - the underlying database, whether it be MySQL, PostgreSQL or Oracle - will always be a relational database, and SQL is the only proven, standard language for dealing with an RDBMS. Inventing a different language seems a complete waste of time to me.

    Quote Originally Posted by allspiritseve View Post
    This approach links objects directly to tables 1:1, and that is not always desired.
    It may not be in YOUR methodology, but I have built an entire development framework around that simple notion. I can build my database, import the table structures into my data dictionary, then export those structures to my PHP application in the form of class files, one per table. I can then create transactions to maintain each table's data by selecting a table, selecting a transation pattern, then pressing a button to generate the necessary scripts. I can end up creating a fully functional set of web pages to maintain and view the contents on a database table in a matter of minutes without having to write a single line of HTML or SQL.

    My methods may make some OO purists choke on their cool aid, but my methodology yields results, and producing results is better than blindly following a set of artificial rules.

  23. #23
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by Tony Marston View Post
    It may not be in YOUR methodology... My methods may make some OO purists choke on their cool aid
    I know RADICORE inside and out, Tony. Unfortunately I have come to the conclusion that it's not my cup of tea... er, cool aid.

  24. #24
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    My methods may make some OO purists choke on their cool aid, but my methodology yields results, and producing results is better than blindly following a set of artificial rules.
    Until, of course, your methodology breaks down because the structural rules it should follow aren't being followed.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  25. #25
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arkinstall View Post
    Until, of course, your methodology breaks down because the structural rules it should follow aren't being followed.
    Please, please, don't argue with him. It's a lost cause, and will completely derail the topic.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •