On Fri, Oct 04, 2002 at 09:02:02PM +0000, Strom McLeod wrote:
> --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
> > I'm more accustomed to seeing MVC in reference to GUIs, not just
> > abstraction and encapsulation.
> It's not, it's a pattern for developing the whole system, not just the
> > Not necessarily. There're two ways to implement a system that uses
> > Oracle.
> The whole point is to not need to specify exactly what database will
> be used and allow that to be abstracted throughout most of the system.
Yep. I discussed Oracle only as an example, and that I expect that the
general design of the software would be such that, outside what the
implementations need to know, they don't need to know anything else.
The specific example I used was that the data engine, if constructed
correctly, will not need to know about the particular source used
(database, XML file, LST file, etc.).
> You specify the details of the database/datasource to be used in a
> configuration file, in addition to a nickname that will be used to
> reference that database/datasource. You can switch databases used to
> realize without changing the nickname.
> The rest of the application uses the nickname to run SQL statements
> etc. without worrying about what driver is actually being used.
> There's no reference to 'Oracle' within the code, only "the database"
> or datasource.
> Technically, you should further encapsulate these SQL statements into
> a data access object/package that the rest of the system calls, so
> that all your SQL calls are centralized into one manageable place.
This is what I would do.
> Now, if you've already got how you want to architect and design this
> in mind already, as the rest of your post suggest, and given that I'm
> not even a recognized primate, I'll leave it be.
The conversation has been useful. It's brought things to mind that I
hadn't considered, or only superficially. I hope to be able to present
something significant for discussion and dissection soon... but I've
been saying that for a while now :/
You do realize that we've been arguing the same points? <g> The only
thing we've actually disagreed on is how to handle certain types of
error, and in both cases the stances were based on different design
styles and different languages... as for the rest of it, I can't think
of anything either of us said that actually excluded what the other did.
I do have strong opinions how my code should be built. I'm the one
building it <g>. PCGen uses different technology (Java), and the
techniques used to handle error conditions naturally differ. I'm
working on the XML schema, and while *technically* it doesn't have
anything to do with the program source, I think I must be able to
demonstrate that the XML schema can be used for the purpose it is
designed for. If I build a schema that does describe the data but is
unusable, or causes us to end up with the data model problems we're
facing now, it isn't, IMO, a good schema.
The software design I'm working on in conjunction is only a suggestion
as to how the data can be handled by the software. However, I suspect
that the design may in fact be used. Even if it isn't, I don't want to
present something technologically weak and have it get caught up in
redesign because I did something outright stupid.
PCGen: <reaper/>, smartass
"You just can't argue with a moron. It's like handling Nuclear
waste. It's not good, it's not evil, but for Christ's sake, don't
get any on you!!" -- Chuck, PCGen mailing list