473,836 Members | 1,504 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Bussines objects

Hi!
I'm making a database application and i heard from a friend that it is more
proffecional and easy to do this with bussines objects. Can anyone tell me
where i can find more info on bussines objects and how to implement them
with c#? I would appreciate any help. Thanks.
Nov 16 '05
38 3738
"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> a écrit dans le
message de news: e3************* @TK2MSFTNGP15.p hx.gbl...
Why are some people just always grabbing an extreme end of the spectrum
to make their point. You know very well there are a lot of different
solutions to place behavior correctly.

In fact, there are 3 kinds of behavior on data:
- attribute oriented behavior (ID > 0)
- entity wide attribute oriented behavior (order date <= shipping date)
Both of which belong in the entity
- cross entity entity oriented behavior (customer is gold customer if
ordered at least 10 orders with producs a, b or c in the last X months)
Which belong in an entity that manages the Customer base, their history and
their relationships
the first two are perfectly placable inside entities, the 3rd isn't, as
Only if you design entities that are data-based instead of functional.
you run very soon into problems with fragmentation of functionality,
i.e.: you have a set of functionality defined and the implementation is
fragmented across various entities. This makes a system hard to maintain
I end up with correctly attributed behaviour (Responsibility Driven Design)
No offence, but when I design a business application, I don't think in
classes or objects. I think in entities, their relation between them and
define them in NIAM/ORM models. The customer can perfectly understand
them, as they contain scentences, like "Customer Has Order", "OrderLine
belongs To Order". Throw in the good old stuff from mr. yourdon and you
can perfectly design your system, without having to go through the
awkwardness of using implementation details.

The fun thing is: the design of the application is abstracted: you can
check if it's correct without writing 1 line of code or even think of
which class has to inherit from which. The other fun thing is: if you
use these diagrams as the guides what you have to implement, you have a
1:1 projection of what you have designed onto an executable form of it:
the code and _vice versa_. This means that I can look into the code, and
go back to the abstract models because that connection is there. The
other way around is also possible.
But the same thing applies to UML; classes are entities and entities are
described by classes. Although I would not like to own the company whose
Customers only ever have one Order :-) "Order Line belongs to Order is
perfectly expressed using the concept of Composition.

UML together with OCL allow you to comprehensively model a domain without
touching a line of code. The you can take something like Bold or ECO and it
will generate all the code necessary in Delphi or C# to provide you with an
executable model; change the model without altering the code and the
application will run with your changes in place. Both Bold and ECO even
create the underlying database for you without you having to write a line of
SQL.
MVP framework, hmm. ;)
Nice :-) Design your forms; name your controls with the property names they
are to display/edit and compile your app. No code on any forms.
That model leads to a relational model. You can use that relational
model to build your entities, as they represent the same thing: the
entity. Then you write your BL tier which represents your application
functionality and you place the 3 types of behavior related to entities
at the right places.
Correct, but that behaviour doen't come from a relational model, it comes
from a business model. I have no qualms about designing a business model
before designing either a relational model or an object model. My beef is
with those who think that relational database table layout is a good enough
description of which properties should be part of a class.
DONE. No-one generates a gui from a db schema, as the gui should be
designed for useability and should be the frontend for the functionality
realized by the application. So on a screen you can for example have
customer AND order information. That's perhaps nice for the screen, but
you aren't storing that info together.
Unless you use some of these awful app generators that do everything(??) for
you :-((
Well, how does your software represent objectified relationships which
represent m:n relations?
Depending on the use case, I may use an Association Class, which is
something like a link table. The difference being I can add relationship
management and validation behaviour inside the association class.
A detailed aspect doesnt make something 'wrong', as there isn't a
'wrong' or a 'right' side here. The relational model approach has 30
years of proven technology on their side, you represent a new vision on
the matter. What's right and wrong is therefore a bit tricky to define,
as both camps will say the other side is wrong.


I have never said that the relational model is wrong; it is the best thing
we have for storing data until a decent true OODB becomes viable/affordable.
When that happens, it will be interesting to see how object theory further
evolves.

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Nov 16 '05 #21
Joanna,

Don't let us take discussions on words, this is an international newsgroup,
in my opinion is the most important thing that we understand each other.
It depends on how you look at things. Some will say that a 'SalesOrder'
is a business object, which aggregates the entities (!) Customer, Order,
OrderLine, Address, Employee.. so the software on the BL level can work
with a single object which embeds all the right information: the
SalesOrder.

When I had written this, I would have written "collection of references"
instead or "aggregates ". I *assume* Frans used it as a union and not as a
total.
And they would be wrong. A Sales Order is a Composition that contains 1..n
Order Lines; it also holds references to but does not aggregate a
Customer.
The Order Lines each describe a quantity of a Product to be allocated to
the
Order and hold a reference to that Product.


In my opinion are you wrong in this. A Sales Order is a contract to deliver
and to receive.

(There has not to be orderlines, there has not to be only *one* customer,
there has not to be a quantity of a product etc etc).

Cor

Nov 16 '05 #22
TJB replied to:

Radi Radichev wrote:
Hi!
I'm making a database application and i heard from a friend that it is more proffecional and easy to do this with bussines objects. Can anyone tell me where i can find more info on bussines objects and how to implement them with c#? I would appreciate any help. Thanks.


There are a lot of buzzwords out there and everyone has their favorite
religion and tool to prosecute that religion with. All are designed to
address these problems:

a) Relational databases deal with sets of objects and object oriented
systems deal with them one at a time. Fundamentally, you have to
create collections yourself in object oriented languages, whereas in
relational systems, everything is a collection. In other words, in an
object oriented language, you create a class and then manage instances
of those classes, and in a relational system, you create a set and then
work with portions of that set.

b) Relational databases provide a rich set of tools for transforming
one view of data into another, and, object oriented systems do not.
There is no language level analogue of SELECT in C# or Java or C++ for
example, and, it would be difficult for it to make sense largely
because of those languages object oriented practice to associate date
with code - all of the time. If, for example, you could SELECT pieces
of class X and class Y into a new class, what would you get?

c) Relational databases have facilities to ensure that no information
is added to it that is invalid, and so do object oriented systems, but,
the meaning of what is valid is different between the two.

d) Relational databases celebrate data, whereas object oriented systems
demand that data must be hidden.

Given the above, I conclude that relational systems are actually more
powerful than their object oriented cousins, and with that in mind, I
would model your data in a relational context first and then provide a
thin object oriented wrapper to provide features to your user tier.
Design your database first using standard relational methodologies,
but, with the requirements of your middle tier guiding it.

To do this, we need to have the following minimum requirements going
in:

a) understand what the user interface is supposed to do. In our case,
let's assume they want to be able to:

select a specific invoice from a larger set of invoices.
create a new invoice.
delete an invoice.
add a line item to the invoice.
remove a line item from the invoice.

Notice in the above case that when we say select a specific invoice, we
really mean three things:

select a list of all invoices
select the invoice header
select the invoice line items.

Thus, we arrive at the following "business object requirements"

select a list of all invoices
select invoice header
select invoice line items
create a new invoice
delete an invoice
add a line item to the invoice
remove a line item from the invoice

The most logical thing to do in this situation is to then write our
middle tier that does exactly the above. That is where the arguments
begin. Some people will tell you you need to implement:

an invoice class
an line item class
an invoice factory class.

Then we arrange the requirements into our classes. The key is,
regardless of metholodology used, you have to ensure that your
requirements are accounted for everywhere in your design.

--invoice class
select invoice header
select invoice line items
add a line item to the invoice
remove a line item from the invoice

--a line item class
does nothing but represent the line items

--invoice factory class
select a list of all invoices
create a new invoice
delete an invoice

from there, you would implement the user interface in terms of your
invoice, line item, and invoice factory classes.

Another way to do things would be to use a processor model similar to
that espoused by Ewald. In his model you would:

create a simple class to represent:

the invoice class
line item class

these basically contain data.

then, you have an invoiceprocesse r class, which is viewed conceptually
more as an agent for processing invoices rather than as a physical
implementation of an invoice object.

the invoice processor would:
select a list of all invoices
select invoice header
select invoice line items
create a new invoice
delete an invoice
add a line item to the invoice
remove a line item from the invoice

I like it but many shops do not because the OOP purity nazis are
against it. But then again, OOP purity nazis are hell bent on doing
everything one item at a time and call it more modern, when we've
already been able to deal with sets of things since the 1970s. But at
least if they are making more work for everyone, you can at least
content yourself that it is more billable hours.

Nov 16 '05 #23
Cor Ligthert wrote:
Michael,

I am not sure, what it says is that the (let take your words) flow of funds
is opposite to the flow of goods.

This is (in my opinion) the complete business approach you need for
information because those flows are around the objects that they use (and
get there information from or let them act because of that).


I think you're using a dutch translation of a Keynes term and then want
back an english translation ;).

If you're suggesting that developers should design their software as if
they were real-life processes, I think you're right, but that depends on
how you look at things, as others think completely differently and from
their POV they're also right... :)

Frans
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Nov 16 '05 #24
Joanna Carter (TeamB) wrote:
"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> a écrit dans le
message de news: ex************* *@TK2MSFTNGP14. phx.gbl...
It depends on how you look at things. Some will say that a 'SalesOrder'
is a business object, which aggregates the entities (!) Customer, Order,
OrderLine, Address, Employee.. so the software on the BL level can work
with a single object which embeds all the right information: the
SalesOrder.
And they would be wrong. A Sales Order is a Composition that contains 1..n
Order Lines; it also holds references to but does not aggregate a Customer.


holding a reference IS aggregating, I meant to hold a reference. I
didn't mean to copy the customer fields over to the object. If that was
your interpretation, then I misworded my sentences, I did mean
references to customer, order, orderlines objects.
The Order Lines each describe a quantity of a Product to be allocated to the
Order and hold a reference to that Product.

Your description looks more like an unnormalised Excel spreadsheet :-)


We meant the same, aggregation is also done (IMHO) by adding a
reference to the object you're aggregating inside the object, and which
is controllable via the interface of the aggregating object, so the user
of teh aggregating object can work with one object.
The BO approach can have advantages: you abstract away the contents of
the BO (which entities are aggregated inside it), though at the same
time, it is illogical to place the behavior of a SalesOrder outside the
salesorder. This can lead to fragmentation of behavior which spans more
than one BO. It also leads to problems if I want to use a subset of the
aggregated entities in teh BO in another context: I then have to create
another BO.


As I have already said the benefit of OO design is the correct allocation
and encapsulation of behaviour relevant to the data it affects. I suggest
you look at the concept of Responsibility Driven Design; Timothy Budd wrote
about this in his book Object-Oriented Programming.


the thing is that behavior is not always related to types, but also to
types + data. This is where your system will fall apart, as in data I
can modify it to have a different meaning, but in an object, I can't.
Simple example: I have a customer and I want to promote him to 'gold
customer' which has a relation to a 'benefits' entity collection. In the
database I can copy the record or add a gold customer record to the gold
customer table which has an 1:1 relation with the customer table and its
particular customer record.

Though, how do I do that in memory? do I use external behavior which
applies to data, and which is flexible, or do I use internal behavior
which all of a sudden should change as I have a this customer object and
it has to be promoted to a gold customer object, but casting is of
course impossible.

I know behavior (some behavior) is better placed with the data, and OO
will then work better. Though I strongly believe in pluggable behavior
as well, which is injected due to a mechanism following the strategy
pattern, so you can add behavior to an entity at runtime, for example
adding additional rules to the entity, different concurrency mechanisms...

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Nov 16 '05 #25
Joanna Carter (TeamB) wrote:
"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> a écrit dans le
message de news: eE************* *@TK2MSFTNGP12. phx.gbl...
Please, theory first, practical blabla later.
A relational model is perfectly usable as a foundation for an OO model.
The reason for that is that a relational model represents entity
definitions (Chen, Codd) you can also define in your OO model. A Relational model may well represent entities, but it can only represent
their state, not their behaviour. The best a RDB can do with behaviour is to
have Stored Procedures littered all over the database, with no encapsulation
between data and behaviour.


no, behavior is applied to the data in relational model at runtime,
it's up to the developer where the behavior is placed. I don't really
see why you argue with this argument, as the people who create their
BO's from entities in the relational model also place their behavior in
these objects for the most part, which is a natural thing to do and is
exactly what you'll do.
*The* fundamental difference between a relational model and an object model
is that the object model aims to encapsulate data, related behaviour and
responsibility in the one entity instead of having to link those things in
application code.
but, data + behavior on data != application.

The silly thing is, if you start with the domain model and generate a
database from it, or when you start from the relational model and
generate classes from it, teh end result will often look completely the
same. So what's the big deal you're arguing about? That your classes are
formed after modelling data + behavior? But ever looked into how a
relational model is formed and how for example DFD's and DSD's are used
to construct an application?

You seem to argue that that approach is unsufficient to write good
software. No offence, but that doesn't show a lot of knowledge of what
has been used for oh, the last 20, 30 years. Please, don't make this
into a 'your way is wrong' discussion.
If you use for example NIAM/ORM (Halpin, Nijssen) to model your
relational model, you'll have an abstract model, which is used to
produce your relational model, but also is a perfect base for your OO
version of that relational model. After all, the abstract relational
model IS the modelled version of the reality.


I would have to strongly disagree with you; an abstract relational model is
just what is says it is: an abstraction of real life bound into a model that
is more concerned with relationships (PK/FK) than it is with an accurate
representation of the real world.


It models the relations between real-world entities and what these
entities contain. It doesn't model behavior, correct. There are other
modeling mechanisms for that. After all, the classes generated from a
relational model don't have build in behavior as in business rules, as
these have to be added by the developer. That is IMHO the same way as
you'd do it. The only thing is: the way the project is set up before
people even start to think about a 'class' is different, and uses
different constructs.

Furthermore, there will be behavior outside entities in stateless
classes, which are applied to entities, probably graphs, and which
represent business processes. The great thing of these is that you can
model them after the real processes they have to automate. This greatly
enhances the maintainability of your software as you have a theoretic
description of your process and you have a 1:1 projection of that in
executable form. Wasn't it Evans who argued for a language to reach that
same level in DDD, to overcome the burden DDD has where translations
have to be made from real world processes to executable code?
There is certainly an abstract model that reflects the real world that is
neither relational no object and it is possible to derive both relational an
object models from it. But you will find that the object model requires less
'massaging' to get it to work almost exactly as the real world.
I don't find that true, as I look very differently at how software
should be written. I admit, I'm schooled with old-skool material, before
OO was mainstream at universities, so seeing the world and seeing the
business processes as OO processes, is IMHO a bit weird. However I can
understand that if you didn't have to learn everything Yourdon cs.
wrote, but instead learned what Evans and Fowler decided was the way to
do it, the world might look a bit differently, as in: how you look at
things and thus how for example business processes should be modeled.

The funny thing is about these type of discussions is that there are
apparently 2 distinct types of creating these business layers, but at
the same time, both forget that either of them can lead to a perfect
software product, however from the other's POV it looks awful.
It depends how you look at things. If you like the theory behind the
relational model (you know, 30 year old proven technology) and you also
like OO languages, you can perfectly merge them, if you start with the
relational model and use that model to use it in the OO world.


That's the problem; I don't like the theory behind the relational model. It
forces the model away from reality in order to comply with the rules of a
storage mechanism.


Then you didn't understand the relational theory IMHO ;).
Your class model for example, produces slow(er) code: to add the
OrderLine to the database, I have to have a live SalesOrder object.
Though it should be enough to just have the SalesOrderID.


I very much doubt that, which takes longer: inserting a Sales Order record
followed by a number of Order Lines within one transaction, or inserting a
Sales Order followed by a number of Order Lines within one transaction ??


No, inserting a set of orderlines in 1 transaction or inserting an
order object and a set of orderlines in 1 transaction.
Deleting 1000 objects from the database, same thing.

With an OPF, same SQL, same thing.


no, don't cheat ;). a true O/R mapper and a true domain model work
solely with objects. This means that if I want to delete 1000 objects
directly from the db, I can't do that, I have to load them into memory
first. Otherwise you'll break the concept. You see, the real issue is
the definition where the habitat of teh entity is: the memory or the
database. DDD defines it in memory. This means that to be able to work
on an entity (delete, add, modify etc..) you only work in memory, as
entities live there.

Going below that and executing a single delete query which deletes 1000
entities from the db is not correct, because it suddenly assumes that
the real habitat of the entity is the database... erm.. that's
conflicting with the earlier definition where the entity lives.
Showing 100 sales orders with the customer name in a flat list? you
need to load the customer object as well. The relational model offers
you the power to do that differently: create a new attribute set (==
entity) on the fly.

You really haven't worked with OPFs, have you ? :-))


I wrote one of the market leading O/R mappers for .NET, let's say I've
been writing O/R mapper engine code for oh, the last 3 years, full time? :)
A well designed OPF is a highly optimised piece of kit that only loads IDs
and enough properties (usually one) to allow users to browse lists. Thus to
load a Sales Order, your generated SQL would look something like :

SELECT ID, ORDER_REF, ORDER_DATE, CUSTOMER_ID FROM SALES_ORDER WHERE ....

Certainly an object is then created for each Sales Order but not all the
properties are loaded; the rest can either be loaded on demand or the full
object will be retrieved, based on the ID, when the object is first shown
for editing. The only time that full objects are ever loaded is when one of
them needs editing; the others in the list remain as partially loaded
objects.
That's one way to do it. You can opt for full lazy loading, partial
lazy loading or load the objects in graphs at once, one query per graph
node (prefetch paths, so fetching 10 customers, all their orders and all
their order lines results in 3 queries).

Your approach as a bit of a problem with compound PK's (it forces a
single PK for entities, which can be a problem with objectified
relations) and you need more roundtrips to the db.

What I meant was that if I want to show a list of data, say 4 columns
from a set of orders and the company name, in a flat list, I just need 1
select statement and a container for that list. It's way too inefficient
to make objects first, then create a property in the order object to
reflect the customer name and make that work in databinding scenario's:
just pull the list and show it.

It was perhaps a bit of a mean example from me, I admit. The one area
where pure O/R mappers (i.e.: just objects, no other things, so no
self-constructed lists from attributes of related entities) fail is in
reporting and other list-oriented software. I mean: creating an
aggregated list of grouped data which contains data from 3 entities, is
a bit of a pain in a pure O/R mapper as it doesn't know the concept of a
field, it knows the concept of an entity.
Object properties (like Customer) contain a Customer object that only has
the ID and Name properties loaded.

I have been working with OR mapping for many years now and certainly started
with the view that classes could be derived from tables, but my years of
experience have matured my views to realise that there is a very real
impedance mismatch between relational and object models. See my example of
the Sales Order; a relational model will treat an Order Line as a separate
entity from the Sales Order that it is a part of; the object model enforces
the composite nature of the relationship by ensuring that the only way you
can add a new Line to an Order is by asking the Order to do it for you.
Since when did you ever see a real world Order Line that wasn't contained
*within* a real world Sales Order ?
If I read a single order line, it's not contained in an order object
per se. The fun thing is: it IS contained in an order entity, but that
order entity isn't loaded into memory. Now, that last sentence is very
important: it really depends on where you define the habitat of your
entities. I define that in the database, and then the relational model
is a cornerstone of my solution space: the entities live there, inside
the structures defined by the relational model. The relational model
provides the context in which the entity data is given meaning.

This clashes with your POV, in which an entity lives inside the memory
space as an object. I can perfectly understand that. However it's a
thing of different perspective on how data should be treated. You use a
totally diffent theory than I do. For me that's perfectly fine, as long
as I'm not told that I'm doing things wrong if I'm just using 30 years
old proven technology.
The object model also allows concepts foreign to relational modelling like
inheritance, aggregation and composition. Concepts that are very much a part
of the real world but that take a lot of effort to match in the relational
model; I should know, I have to write the OPFs that cross the mismatch :-)


You make 1 mistake: the way inheritance works in classes is not the way
inheritance works with data. The problem is that with data, I can 'cast'
data from one type to the other in a database with 1 DML statement. With
classes I can't: I have to migrate the container (object) the data is in
to another type of container. For example in the situation in which I
have a manager entity object and I want to promote that manager to an
executive entity. An executive entity definition inherits from the
manager entity definition and has an extra relation: to companycar.

Now, in your world, load a manager entity into memory and promote it.
That's pretty problematic, you can't cast the manager entity to an
executive entity of course, you have to create a new executive entity,
copy over teh data and save it.

the problem is: you've modeled it as Manager table and Executive table,
and Executive table has just the Manager PK as an FK to Manager and an
FK to companyCar. Saving teh Executive again, creates a dupe in Manager.

All of a sudden the relational model is there, something you wanted to
avoid in DDD. ;)

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Nov 16 '05 #26
TJB replied to:
And they would be wrong. A Sales Order is a Composition that contains 1..n Order Lines; it also holds references to but does not aggregate a Customer. The Order Lines each describe a quantity of a Product to be allocated to the Order and hold a reference to that Product.
This is just shorthand for a relational representation. It's just
that, in C#, the address of the reference is its implicit foreign key.


Your description looks more like an unnormalised Excel spreadsheet :-)

And Excel is more powerful than C# in some ways because it is a
declarative language whereas C# is merely imperative. If Excel were as
primitive as everyone says, we wouldn't have vast IT budgets trying to
replace just a few of the key spreadsheets.
And they also would be wrong. Does the fact that a Sales Order is put away in a drawer mean that its Lines become separate entities, except when I want to look at the Order
Interestingly, this is exactly what C# and all OOP languages do.
There's no physical ordering of memory associated with an object. A
invoice and its components live scattered all across the heap and have
no spatial relationship whatsover.

The reality is that OOP systems are just short hand for a lightweight
relational system that uses memory addresses as primary keys. This is
easily observed by attempting to save an object to disk. All of a
sudden, those little references must be replaced by a more suitably
persistent identifier.

In a relational database, I can get all sorts of different views of the
data. I can get sales by item, sales by invoices, all from describing
the relationships of data once and only once. OOP is so infatuated
with hiding data that allowing one to produce new class types on the
fly (which SELECT does), would practically be heresy!
As I have already said the benefit of OO design is the correct allocation and encapsulation of behaviour relevant to the data it affects. I suggest you look at the concept of Responsibility Driven Design; Timothy Budd

wrote

OOP design is shorthand for relational design and it is not nearly as
flexible and is already proven not as correct. OOP specifies
relationships between data by the use of a class hierarchy, and, in the
database world, this practiced stopped by the 1980s. Yes, you would,
in Pick on an RS/6000, maintain associations between items by either
containment (invoice line items in an invoice), or by physically
setting a pointer. The problem was that if you moved what was pointing
to, you had to move the pointer as well. So, we further in more purely
relational models abstract out the idea of what an instance of
something is by specifying its relationship through declarative foreign
keys.

There is enormous amount of evidence to suggest that object oriented
systems have to some degree not lived up to their promise, whereas data
driven approaches have always exceeded theirs. First off, they still
require relational databases to back them up. Secondly, they remain
extremely expensive to develop, even with tools as excellent as Visual
Studio.NET is today. And, finally, many of the things that are being
developed in object oriented systems are being replaced by declarative
systems. We used to do client server systems by hand, then, user
interface coding gave way to the declarative ease of use of HTML.
Even Windows Forms is being replaced by Avalon, which is ultimately a
declarative framework for everything known to mankind about user
interface design.

The reason for this is simple, stunningly simple. Object oriented
systems are imperative systems, and deal with things one at a time,
whereas, declarative systems deal with sets of things.

It remains a simple problem then to handle the transformation from the
schema of a user interface to a schema of a relational database, and
even things like XSLT prove that this is possible. .NET is in fact on
the verge of doing both and in doing so make itself obsolete. The user
interface designer of Visual Studio.NET is essentially a lightweight
database done through reflection. Most of the static forms cases are in
fact through property settings - clearly data only. SQL Server is
building powerful transformation features into it. Our future world
may well be a SQL Server that simply spits out user interfaces as just
another query.

OOP will go to the dustbin of history, and soon, because computers are
about data first and code second and OOP gets it backwards. In the
near future there will be tools that allow us to express declaratively
the relationships between items. In the near future, there will be no
code, only data.

Nov 16 '05 #27
stork <tb******@might yware.com> wrote:

<snip>
OOP will go to the dustbin of history, and soon, because computers are
about data first and code second and OOP gets it backwards. In the
near future there will be tools that allow us to express declaratively
the relationships between items. In the near future, there will be no
code, only data.


Ever tried XSLT? That's what happens when you try to write code
declaratively. It's a mess.

There are some things which are best done declaratively, and some which
are best done imperatively, in my view. Trying to make everything go
either one way or the other is a mistake. Mix and match to get the best
of both worlds.

Just out of interest, how soon do you think "soon" will be? Fancy
making a prediction we could actually test? Do you think OOP will be
obsolete in 5 years, say?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #28
Radi... As you can see there are minor differences of opinion on this
subject :). There is little downside to proper database design. The
database is the last line of defense against data corruption.

I am having fun turning my Visual Studio IDE into FileMakerPro,
generating drag and drop printable WinForms against MSDE. This is made
much easier by the ability to inherit from existing WinForm controls.
IMHO the prediction of the demise of relational databases and/or object
oriented programming is premature.

http://www.geocities.com/jeff_louie/OOP/oop24.htm

Regards,
Jeff
I'm making a database application and i heard from a friend that it is
more proffecional and easy to do this with bussines objects.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #29
TJB replied to:

Ever tried XSLT? That's what happens when you try to write code
declaratively. It's a mess.
XSLT fails not because of what it does but because of how it does it.
The syntax is just genuinely aweful!

There are some things which are best done declaratively, and some which are best done imperatively, in my view. Trying to make everything go
either one way or the other is a mistake. Mix and match to get the best of both worlds.

For right now, I whole heartedly agree. That's why I like to go:

1. User interface design and business requirements
2. data relationships
3. object middle tier in some fashion.

Pretty much for me OOP stuff in C# is the bridge between 1 & 3.
Just out of interest, how soon do you think "soon" will be? Fancy
making a prediction we could actually test?
Hey there's no penalty for being wrong, so I'm game!

:-)
Do you think OOP will be
obsolete in 5 years, say?


The first languages to do so will emerge from the labs by then, yes.
But it will be at least another decade after that until declarative
languages are truly everywhere.

Nov 16 '05 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
8258
by: dasod | last post by:
I would like to know if my method to remove list objects is correct in this small test program. It seems to me that there might be a simplier way, but I'm afraid I don't know enough about list iterators and how they are behaving in situations like this. #include <iostream> #include <list> class Test; typedef std::list< Test* > Tlist;
11
1800
by: thechaosengine | last post by:
Hi all, I have a very general but quite significant question about objects. My question is, when should I create them? I know thats a crap question so let me explain a bit further. Lets take an example of user management against a database. Things I might like to do include:
9
1896
by: Aguilar, James | last post by:
Hey guys. A new question: I want to use an STL libarary to hold a bunch of objects I create. Actually, it will hold references to the objects, but that's beside the point, for the most part. Here's the question: I want to be able to change the references (including deleting them). Is there any way to do that besides using pointers rather than references for the STL library? I'd also prefer to avoid using const_cast, if it is indeed...
6
2584
by: Alfonso Morra | last post by:
I have written the following code, to test the concept of storing objects in a vector. I encounter two run time errors: 1). myClass gets destructed when pushed onto the vector 2). Prog throws a "SEGV" when run (presumably - attempt to delete deleted memory. Please take a look and see if you can notice any mistakes I'm making. Basically, I want to store classes of my objects in a vector. I also have three further questions:
161
7924
by: KraftDiner | last post by:
I was under the assumption that everything in python was a refrence... so if I code this: lst = for i in lst: if i==2: i = 4 print lst I though the contents of lst would be modified.. (After reading that
7
8228
by: Jo | last post by:
Hi, How can i differentiate between static and dynamic allocated objects? For example: void SomeFunction1() { CObject *objectp = new CObject; CObject object;
21
2226
by: George Exarchakos | last post by:
Hi everyone, I'd like your help... Can we have a std::list<BASEwhere BASE be the base class of a class hierarchy? I want to add to this list objects that are inherited from BASE class but not necessarily the same... class base { int x;
27
2573
by: SasQ | last post by:
Hello. I wonder if literal constants are objects, or they're only "naked" values not contained in any object? I have read that literal constants may not to be allocated by the compiler. If the Standard is saying that "object is a region of storage", I deduce from that that literal constants aren't objects because they may not be alocated as regions of storage in the memory.
14
6035
by: Jess | last post by:
Hello, I learned that there are five kinds of static objects, namely 1. global objects 2. object defined in namespace scope 3. object declared static instead classes 4. objects declared static inside functions (i.e. local static objects) 5. objects declared at file scope.
0
9820
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9670
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10548
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10591
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10254
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9374
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5649
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4452
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3115
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.