|
MadHatter ¢ wrote: I don't see much use in a business/data layer if you're a framework / component developer.
Have a look at DotNetNuke and look at the way it does components (modules).
|
|
|
|
|
you obviously have application module confused with framework and component development.
you don't need much of a data or business layer for things like menu, toolbar, navigation, grid, or other type of controls you typically buy from product based 3rd party component developers. dnn is an application, and things built for it are application specific, one could say, business logic specific, and therefore are not component objects in the sense that the others are.
thats not to say the obsessive developer who knows nothing outside of an n-tier architecture wouldn't try to write components like that (heavens knows the people at my work would try, as anything without a business object is just wrong).
business and data layers are used for data persistence in scalable applications. if 1) your code does not apply the logic of data persistence or 2) is not a scalable collective of objects, then it is not even a candidate for these "layers.". if you have a toolbar that will open and save its data to some isolated storage file, then there is no need to abstract out that functionality so it can be extended to godonlyknows because it will never need to be overridden by the user of that component. if you're writing a framework (.net framework anyone?) and you're implementing some application configuration class, why not hard code the layer that actually loads the file? because thats the route Microsoft took.
thats the kind of thing I'm talking about.
|
|
|
|
|
games 
|
|
|
|
|
ed welch wrote: games
Ah.... Fair enough. I never thought of that. 
|
|
|
|
|
Heh heh... I'll chomp. 
Asset management:
Where are your textures located, where on disk, so you have a resource manager.
Data Access Layer.
Sound, Texture, Mesh, Not to mention scripts for game objects, which brings me to:
Game Objects:
Characters, vehicles, triggers, AI, etc.
Business Objects.
Graphics Engine:
Then you have the rendering pipeline, the graphics engine, which correct me if I'm wrong, falls into...
Presentation Layer.
Just about every game consists of the same pieces as a business app, they're just grouped differently.
This statement was never false.
|
|
|
|
|
Chris-Kaiser wrote: Where are your textures located, where on disk, so you have a resource manager.
sorry man, but thats file IO not data access. layers represent abstracted functionality, chances are you couldnt store the resources in anything else but in file. the whole idea behind a data access layer is that you can change the data repository without affecting the application. if your resource manager simply opens a file, then you're going to be hard pressed to switch out that functionality without having to rewrite the whole thing.
Chris-Kaiser wrote: Game Objects:
Characters, vehicles, triggers, AI, etc.
Business Objects.
business objects reflect the database they're stored in, so, no, those are just objects. they are not subject to change in game, and do not require updates to what they look like. a business object would be a player account object, which would get updated when you payed your monthly subscription fee... I have seen games written using these layers, and its not to say that a game *couldn't* implement these things, its just that game developers come from a different school of thought (small, concise, and light weight).
Chris-Kaiser wrote: Graphics Engine:
Then you have the rendering pipeline, the graphics engine, which correct me if I'm wrong, falls into...
Presentation Layer.
Just about every game consists of the same pieces as a business app, they're just grouped differently.
I wonder if you've ever participated in a strict n-tier system. presentation layers are capable of rendering business objects. business objects are capable of accessing the data layer, and the data layer is responsible for persisting its state to a data repository. drawing a player model does not represent a presentation layer. it is data presentation, but not in the same sense that an architecture that *actually* implements these abstract layers.
every program has IO, business logic, and some have a UI. these are not the same as an abstracted n-tier architecture, otherwise every application in the world would be some massively scalable system.
|
|
|
|
|
MadHatter ¢ wrote: sorry man, but thats file IO not data access.
Sorry man, but if you're thrashing your cache by not reusing your textures due to not managing them in a "data access layer" or resource manager, then the game will not preform well most of the time, unless its a trivial game.
You have a host of textures, meshes, skeletal files, etc. Hopefully aligned on the disk according to access grouping, but still, you won't be able to hold everything in memory, so for a given level you'll load most of what you need, but on systems that don't have a gig of ram, PS2 for instance, then you'll have to have a priority based system that loads what's needed, caches it, and dishes it out to the game objects that need it. Prioritized so that if it fills up and a request comes in that isn't cached, the least used resource will get tossed. So this is a data access layer, just not in the sense that you are thinking about it. You have to manage your data access.
I suggest that you read Scott Bilas' article[^] that was in Game Programming Gems 1 regarding resource management and how its really a database. His view even holds that every application is a database due to the very nature of managing data.
MadHatter ¢ wrote: I wonder if you've ever participated in a strict n-tier system. presentation layers are capable of rendering business objects. business objects are capable of accessing the data layer, and the data layer is responsible for persisting its state to a data repository. drawing a player model does not represent a presentation layer. it is data presentation, but not in the same sense that an architecture that *actually* implements these abstract layers.
I bet you do.
I work on one now. N-Tier, an application tcp server that our web accesses as well a traditional gui, then there's the mobile apps I build that interface with that app server through a webservice. I also have to maintain a disconnected database on the device and manage a transaction server to upload them when connectivity is established. All of it is dynamic in that the main framework knows nothing of the business at hand. It interrogates assemblies to get the data definitions, business libraries, and embedded modules.
I have also worked on large scale game development. The last one in 1999 for Angel Studios on the Smuggler's Run PS2 launch title. They got picked up by Rockstar and are now Rockstar San Diego.
So, while you may think I'm speaking out of my ass, I have experience with what I'm saying on both the enterprise and game dev fronts. Its not just theoretical.
Next.
Addendum: Also, the rendering pipeline... its a presentation layer. The graphics engine. If your game objects need to know whether they needs to use DirectX or OpenGL, then you haven't abstracted your presentation layer enough.
This statement was never false.
|
|
|
|
|
MadHatter ¢ wrote: business objects reflect the database they're stored in, so, no, those are just objects. they are not subject to change in game, and do not require updates to what they look like. a business object would be a player account object, which would get updated when you payed your monthly subscription fee... I have seen games written using these layers, and its not to say that a game *couldn't* implement these things, its just that game developers come from a different school of thought (small, concise, and light weight).
Missed this section in the last reply.
Business objects don't have to reflect any database. They can comprise data from a table, multiple tables, or even from a webservice. Say, a stock ticker. This is some pretty limited thinking on your part. I take it, you don't like that language of: Data/Business/Presentation.
A business object in the game context would be say: an NPC. Its comprised of base data: sound, texture-mesh-skeletal(3d)/png(2d), then behaviors from either a script (acquired through the resource manager(data access) *, and will be called upon by the graphics engine to either draw itself, or to obtain the files necessary to draw it by the engine itself. So all three pieces are still in play. The model still fits.
Now to have a truly data driven solution you'd want to break these out into the different layers. The GameObject would load its resources from the resource manager. The manager will only retain a single copy, even though multiple game obejcts might be using it, in the case of trees for instance, and HOPEFULLY your game objects are going directly to the disk to get the resources themselves. The AI subsystem would also query the game objects to get at the resources required, to perform the update.
Anyone who thinks that a game doesn't also consist of these layers hasn't thought it out, or are biased against the language such that they just can't see it.
See the link I gave in my other reply. Game developers are moving more in the direction of breaking up the projects in this manner. Especially if they are licensing a game engine.
This statement was never false.
|
|
|
|
|
you've missed the forest for the trees dude.
MadHatter ¢ wrote: I have seen games written using these layers, and its not to say that a game *couldn't* implement these things, its just that game developers come from a different school of thought (small, concise, and light weight).
I wouldn't say you're talking through your ass (nor do I think thats what I implied), but I think you're missing the point I was trying to make 
I've both seen and written games that use a fully blown n-tier architecture, but I have actually seen more (and would say that the majority of the engines out there today do not implement such) that do not... that is to say, you could not exchange their <insert layer / concept here> data access layer without a ton of re-engineering.
|
|
|
|
|
MadHatter ¢ wrote: you've missed the forest for the trees dude.
So have you.
MadHatter ¢ wrote:
I wouldn't say you're talking through your ass (nor do I think thats what I implied), but I think you're missing the point I was trying to make
I've both seen and written games that use a fully blown n-tier architecture, but I have actually seen more (and would say that the majority of the engines out there today do not implement such) that do not... that is to say, you could not exchange their <insert layer="" concept="" here=""> data access layer without a ton of re-engineering.
Well, your missing the point I'd say. Since the point is that these layers exist in games and you seem to be denying it to an extent. I'm only saying that these layers exist regardless of how you choose to think about them.
It appears to me that you are being a stickler for a hard line definition of the layers. I'm going for a more loose interpretation. Regardless of how "coupled" they are.
Argue all you want. But the layers are there. If you don't like that.. whatever. L8r dude. You can see it your way, I'll see it mine.
This statement was never false.
|
|
|
|
|
void main() {<br />
printf("hello world");<br />
}
I cannot call that a presentation layer. sorry.
|
|
|
|
|
Neither would I. Sorry, but is that all there is to your software?
This statement was never false.
|
|
|
|
|
>I don't have any Data Access Layers, Business Logic, or Presentation Layers
Yes you do. Those are generic terms applicable to all types of applications. In case of a game, for example:
Data Access Layer: Load level data, Save player data
Business Logic: Process user input, enemy AI etc.
Presentation Layer: User Interface aka Rendered Graphics.
|
|
|
|
|
there is data and drawing code, I do not deny that, but each class handles it's own stuff. Using the word "layer" indicates, for instance, that all the drawing code is in one place.
|
|
|
|
|
> Using the word "layer" indicates, for instance, that all the drawing code is in one place.
Not really. A layer can consist of many classes. It's just one possible view of the system, just like partitioning a system in classes or files.
|
|
|
|
|
So you are saying there's "a presentation layer" in there somewhere amongst those classes, even though none of the classes are organised in that way?
|
|
|
|
|
Perhaps erroneously so, but my impression of this layered scenario is something to the effect:
Call-it-what-you-will Function<br />
Presentation Layer ------ Get the data from something or someone<br />
Business Logic ------ Checks out the data: validates, processes, etc.<br />
Data Layer ------ Data storage
It all seemslike yet another jargon to dazzle spectators and listeners. It perhaps servers a purpose beyond that, which I may learn to appreciate. Does it really clarify compared to whatever descriptions it replaces? That's the question.
Balboos
Note On my modification: Is there an easy way to have neat columns with these posts?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
|
|
|
|
|
jeroen94704 wrote: > Data Access Layers, Business Logic, or Presentation Layers
Those are generic terms applicable to all types of applications.
No. Those are hollow terms used by low aperture business-software-manager guys to obfuscate where the real work is done.
I admit that this type of industry is booming ATM. But nonetheless they should stop seeing their poit of view as the only one.
Sorry for the rant...was nothing personal.
Failure is not an option - it's built right in.
|
|
|
|
|
Whatever you call it is irrelevant. A layered model is a useful view of a system in some contexts, just like other views are useful in other contexts. Someone who draws nothing but a static class-diagram and calls it "design" has no right to call himself a Software Engineer.
Nothing personal of course 
Jeroen
|
|
|
|
|
Deployment?
Brad
Australian
- Bradml on "MVP Status"
If this was posted in a programming board please rate my answer
|
|
|
|
|
It's there at least...
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!
|
|
|
|
|
Sorry, that's been outsourced to India.
/ravi
|
|
|
|
|
Does you app have a user interface? Behind that user interface are you Doing Stuff With Data? What about inputing and outputing data your app uses from a file store, database, network...?
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Hmmm... no, just having lines of code and making them do something
e.g. I hate arranging controls -it's tedious, and everybody has his own most important button that must be bigger thaan the rest. But wiring the controls to "think ahead" and give a smooth UI experience is fun again
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!
|
|
|
|
|
DUH! -- the guy forgot the most important part!!!
Ditto here!
You can disregard all of the other options.
Ha, ha, ha.
David
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
