The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

need help with model interface (MVC)

I am trying to implement MVC, and I just need validation that what I am doing for the "model" is about right.

The overall picture: The data is stored in tables in a database file. The "model" is responsible for handling the database. The controllers that interact with the user via GUI elements use the model's API to read/write the data in the database.

This results in a big API for the model. I am debating whether I should ditch the API and have the controllers talk to the database directly using SQL. Currently the API interface does that so the controllers don't need to know about the database or SQL.

Is it OK to have a big API interface? Is there anything I should be watching out for?
rookie_coder
Monday, January 29, 2007
 
 
A couple of things to watch out for:

If your app is simple enough that the controller can just execute SQL, MVC may be overkill.

If not, make sure that your model is providing a "business domain" API, not a database API. A single business operation often uses several database operations.
Mike S Send private email
Monday, January 29, 2007
 
 
Sometime back I had created a model layer with lots of APIs. What I found out was that it was too time consuming to create and maintain them, but most of all, I found it that the APIs could deviate from any standard, so two or more applications could have very weird APIs, with some supporting subsets of each-other features.

Then I added another layer with metaprogramming to make it more standard for the basic operations (Create, Read, Update, Delete), while allowing for extra APIs which could be further customized for the domain.

It was the best of both worlds, and I think when folks use Hibernate or ActiveRecord, it's close to this design. The basics being handled automatically, while you can add extra stuff as needed.

If you can adopt an existing ORM tool, you may join us. :-) Otherwise, it will be rather difficult.
Lostacular
Monday, January 29, 2007
 
 
If you are using ColdFusion, I recommend Reactor, it works great for abstracting database stuff for you.  We write web services in ColdFusion that consume Reactor and contain business domain level API functions.
Eric Knipp Send private email
Monday, January 29, 2007
 
 
"I am debating whether I should ditch the API and have the controllers talk to the database directly using SQL."

Not to be mean, but if you're asking this question, then by all means go ahead and use direct SQL. The only advice I'd give in this case is to physically place the actual SQL calls in a convenient file or two, and invoke them through their function wrappers. In other words, you write a save_record( x, y, z ) parameterized function that contains the actual SQL code. This satisfies the model aspect in the sense that if you port to a different database, you only have to replace a couple of files.

If you need a true database API, you're generally dealing with transactions that involve multiple tables, integrity constraints, triggers, exceptions, logging and so forth. For example, every time you issue a payroll check, you may have to verify that the employee exists, is still employed, has a valid mailing address, and then subtract taxes, benefit payments, leins, etc etc. All of this logic should be wrapped up in a single transaction, hence a database API rather than a business (or controller) API.

But as far as MVC is concerned, the key issue for you is that you want to swap databases - from Access to MySQL to Oracle to whatever - with a minimum of effort since all of the data (or model) code is consolidated in one place.
TheDavid
Monday, January 29, 2007
 
 
This is a tough one to answer without more background, unfortunately, since in some form or other, the ultimate answer is probably some variation of that good ol' non-answer, "Well, it depends."

Are you building a simple, super-specialized app that'd take you a couple of days and serve a small business need?  If so, a big API's probably overkill -- unless of course you want to use the little project as a learning experience, which would be fine, depending on who's signing your check. =)  So yeah, it kind of depends.

To answer your question, though, yes, by all means -- it's conceptually fine to have a "big API"; APIs are generally larger and more complex that the code that uses them, since they're intended to simplify that code by definition.  But by the same token, to second TheDavid, if you're uneasy about whether it's even warranted in this case, you're probably right.
Chris
Monday, January 29, 2007
 
 
The model API seems to be doing two things for me. It is interacting with the raw data (database file) while providing a more business-logic type of interface to that raw data so the users of the API don't have to worry about it.In some cases, the business logic is nothing more than filling in the database tables one-to-one, so it is trivial, but that's probably just a coincidence.

The model API will not (or should not) have to change even if I change the database structure, or the logic it implements. It provides that nice separation.

I have nothing against the big API, just got alarmed when it started growing.
rookie_coder
Monday, January 29, 2007
 
 
"...just got alarmed when it started growing."

Fortunately, when you realize everything is essentially a create, insert, update, select or delete operation, you can pretty much impose a finite cap on the size of the API.

For example, I have an application that consists mostly of trivial tables (and very few joins). I wrote three routines corresponding to insert, update and select, and passed the table name and columns as arguments. Four if you include the select two joined tables. If I needed to insert or update into multiple tables, I'd do it in a transaction which called one of the four base functions multiple times.

So it never became a situation where I had 50 tables, and 150 functions (insert, update and select for each table). My API would only grow if I needed to add more complexity.
TheDavid
Monday, January 29, 2007
 
 
<< This results in a big API for the model. >>

So what? If you have done your job properly you should find that 95% of the code in each model component is the same for each database table. Put all that common code in an abstract class which is then inerited fr each individual table class. The abstract class may be big, but it has to be big enough to do everything it needs to. It is only when it hasmore code than it needs that it becomes too big. If it has less code than it needs then it is too small.

Also, I advise you *NOT* to put data access logic in the model - use a separate data access object (DAO). This, and this alone, should be responsible for constructing and issuing all SQL queries. The model should contain nothing but business rules and task-specific behaviour. There should be one DAO pr DBMS, not one per table. This will then allow you to switch from one DBMS to another simply by instantiating a different DBMS class.

If you end up by writing custom controllers which call custom APIs in the model then you are doing something wrong. It is possible to write a set of standard (and therefore reusable) controllers, and even views, which means that the majority of your energy can be spent in writing code within each business layer object (model).
Tony Marston Send private email
Tuesday, January 30, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz