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.
38  3677 
A "business object" is just a class that represents a real entity with
which you work. For example, if you work with customers and orders, then
you might have a Customer class and an Order class.
Check out the following link: http://www.mygenerationsoftware.com/...s/dOOdads.aspx
The tool from MyGeneration can create C# code for business objects
automatically from tables in a database. Then you can bind controls in
your gui to that.
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.
"Patrick B" <ne*******@devzoo.com> a écrit dans le message de news:
#R**************@TK2MSFTNGP10.phx.gbl... A "business object" is just a class that represents a real entity with
which you work. For example, if you work with customers and orders, then
you might have a Customer class and an Order class.
Check out the following link:
http://www.mygenerationsoftware.com/...s/dOOdads.aspx
The tool from MyGeneration can create C# code for business objects
automatically from tables in a database. Then you can bind controls in
your gui to that.
As useful as you might think such a tool is, I would seriously advise
against using database design as the foundation for class design. There are
several patterns, like foreign keys, that are not necessarily correct in OO
world.
e.g.
Database
========
SalesOrder
ID
Date
CustomerID (FK)
Tax
Total
OrderLine
ID
OrderID (FK)
Quantity
ProductID (FK)
LineValue
Classes
=======
SalesOrder
ID (unique ID held internally, not used in client code, just by storage)
Date
Customer (object not ID)
Lines (composite list only accessed through AddItem method on this class)
Tax
Total
OrderLine
ID (unique ID held internally, not used in client code, just by storage)
Quantity
Product (object not ID)
LineValue
It is usually the job of a mapping layer to maintain the solution to this
apparent mismatch between the Object Layer and the Database.
Joanna
--
Joanna Carter
Consultant Software Engineer
I wholeheartedly disagree wtih this statement. As useful as you might think such a tool is, I would seriously advise
against using database design as the foundation for class design. There are
several patterns, like foreign keys, that are not necessarily correct in OO
world.
Your application in the end exists only to manipulate data, the data is the
application, everything line of code your write exits to flip a bit or save a
value in your database. Starting with the database and working from the
ground up is an excellent and proven way to write an application, and is how
most do it.
Once you have your database design you can then use that very useful AND
accurate data to generate the classes that represent that data. MyGeneration
does exactly that.
Mike Griffin
MyGeneration Software http://www.mygenerationsoftware.com
"MyGeneration" <My**********@discussions.microsoft.com> a écrit dans le
message de news: D8**********************************@microsoft.com... I wholeheartedly disagree wtih this statement.
You are entitled to your opinion but...
Your application in the end exists only to manipulate data, the data is
the application, everything line of code your write exits to flip a bit or
save a value in your database. Starting with the database and working from the
ground up is an excellent and proven way to write an application, and is
how most do it.
Database design used to be the standard, well-proven basis for non-OO
applpications; I know, I was weaned on Logical Data Structure diagrams.
But where do you put the code that manipulates the data ?
Please don't tell me you use data-aware controls directly connected to
database tables and write the code in event handletrs on the forms!! :-))
Not all data in an application is stored in a database. In a well designed
OO application you may well have hundreds of classes that have nothing to do
with *stored* data.
The frameworks I have written to support my applications contain around 300
classes and interfaces.
There is the Value Type Framework that gives me more metadata about my
business objects and their properties.
There is the Object Persistence Framework that allows me to write OO code
that knows nothing about databases because the OPF translates business
objects to/from database tables, generating SQL on the fly. I only ever use
one Query component, one Transaction component and on database component in
my entire application and frameworks combined.
There is the MVP framework that allows me to replace my UIs without having
to change any of the code in either my business objects or the applications
that use them.
etc...
How would I extract those classes and interfaces from a database ?
What about those applications that don't use databases ?
Once you have your database design you can then use that very useful AND
accurate data to generate the classes that represent that data.
MyGeneration does exactly that.
How does your software translate the Sales Order example I gave ?
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Hi,
"MyGeneration" <My**********@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com... I wholeheartedly disagree wtih this statement.
As useful as you might think such a tool is, I would seriously advise
against using database design as the foundation for class design. There
are
several patterns, like foreign keys, that are not necessarily correct in
OO
world.
Your application in the end exists only to manipulate data,
No really, my application exist to solve a problem to the user. The data is
the core of it , but you cannot design all your application around it, you
have to design your application around the problem you are trying to solve.
Starting with the database and working from the
ground up is an excellent and proven way to write an application, and is
how
most do it.
Totally agreed with you, The DB design helps you identify the potentials
entities involved in the business layer and the relationships among them,
Now where I disagree with you is that you should take into account that the
requirements of the business layer is different that those of the DB layer,
ie you don;t have a third normal form for business layer that can assure you
have a good design.
The relationship among buss. entities are differents and others patterns
exists for this layer.
Once you have your database design you can then use that very useful AND
accurate data to generate the classes that represent that data.
About the original post question....
There are being lot of discussions in this groups about what is the best
approach to handle data in the business layer, You have two escenarios ,
when the business rules are simple and few and no transformations need to be
performed in the data itself, in another words the main use of your app is
showing/editing data. In this escenario IMO is better to keep the data in a
dataset.
IF you have complex business rules and relationships then you are better
creating custom business objects that better describe the problem.
MyGeneration does exactly that.
That may be a very useful tool !!!!
I started using a similar feature in Rational's XDE but I never could figure
out how.
Do you provide a demo version ?
Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
There are samples on our home page. As for a demo version MyGeneration is
100% free, there is no trial version, it's simply free. We also have
Gentle.NET, NHibernate, Opf3, and DAAB templates in addition to our own
dOOdads architecture.
And I don't care what the business requirements are I aways generate the
code and customize from their (without worrying about regeneration), see this
page:
dOOdads at 10,000 feet http://www.mygenerationsoftware.com/...s/dOOdads.aspx
We use this technique on Fortune 50's and 100's and it works everytime, our
clients are simply amazed by our speed and reduced cost, and above all the
maintainability.
dOOdads usage in C# http://www.mygenerationsoftware.com/...terSample.aspx
Everyone has their own opinions sure, but your saying "Don't do that it, it
only works on simple projects" without offering any proof.
Hi, We use this technique on Fortune 50's and 100's and it works everytime,
our
clients are simply amazed by our speed and reduced cost, and above all the
maintainability.
The size of the company does not mean nothing, it's the requirements and
complexity of the system what does.
A complex system will get better beneficies of the framework of course.
dOOdads usage in C#
http://www.mygenerationsoftware.com/...terSample.aspx
Everyone has their own opinions sure, but your saying "Don't do that it,
it
only works on simple projects" without offering any proof.
I did not say that. I said that this is a recurring subjects in the
newsgroup. and that several strategies are followed by different developers.
I personally do not disregard a dataset or datatable to keep data all the
way up to the UI, and do use it when the data is only to get dumped. It has
worked for me before. When using it? well that's the decision (and taste) of
the designer :)
cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Yeah People that's verry nice but what i asked for was some Info on business
objects, not software for automaticaly implementing them.
"Radi Radichev" <co******@minet.uni-jena.de> a écrit dans le message de
news: eZ**************@TK2MSFTNGP14.phx.gbl... Yeah People that's verry nice but what i asked for was some Info on
business objects, not software for automaticaly implementing them.
Business Objects is a term used for any class that describes a business
concept; e.g. Customer, Invoice, Person, Shape, Computer, Vehicle, etc.
The big advantage of using BOs is that all your business logic resides in
those objects rahter than being placed in event handlers on forms.
Most folks who start using a RAD IDE like VB, Delphi or VS, tend to place
database components on a form, hook up data-aware components directly to the
tables in the database and then try to figure out which event to place code
to react to changes in either the tables or edits.
This approach is doomed to fail (or take longer to get right) for all but
the simplest of projects.
If you design your BO layer, it need know nothing about either database or
UIs. This means that all your business logic is encapsulated in the BO layer
and you can change your database or UI without having to re-write.alter any
of your business logic code.
That is essentially what business objects are; however, to use them
efficiently, you will also need some method of translating the values in the
properties of your BOs so that they can either be stored in/retrieved from a
database or displayed in edits on forms.
This is where frameworks like OPF or MVP come in useful (see my other post).
However for UIs created in .NET, as long as your BO classes are designed
correctly, it is possible to use 'data-aware' controls to hook up directly
to the properties of your objects and to your lists of objects.
Does this answer your question any better ?
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
> Your application in the end exists only to manipulate data, the data
is the application.
Well, I wholeheartedly disagree with _that_ statement. :)
Data is how things (business entities) happen to be stored. It is
common practice to put what the business thinks of as multiple entities
into one table (or set of tables), just because they share many of the
same (data) qualities. It is also common practice to split what the
business thinks of as one entity across multiple tables (normalization,
for example).
Where I work, we are dealing with exactly this problem: designing
business objects to represent real "things" in the business, _not_
database tables! Our case is probably worst-case because we didn't
design the database tables and we aren't at liberty to change them very
much. If we used an automatic business-object-generating technology, it
would produce crap: garbage in, garbage out. We're designing the
business layer to _hide_ the baroque complexity of the data model as
much as we can. The last thing we want to do is expose it at the top
level.
Again, that's a worst case. In those cases in which you're designing
the data layer and the business layer, there is a strong correspondence
between the two, but it's by no means one-to-one.
That said, generating a second-rate business layer "automagically" from
a database schema may be, in the end, the most efficient path. It's the
old 80/20 rule: to get 80% of the effect you put out 20% of the effort.
If you want a "perfect" business layer then it's going to cost you big
time. If automatically generated business objects are only 80% as good
as hand-tooled ones, but come at a quarter the cost, maybe that's a
smarter way to go. :-)
In response to the OP, so far I have seen two different approaches to
building business objects in .NET.
The first is the one that Joanna outlined so well in her post of a half
hour ago: build a business layer by hand, where each object represents
an identifiable "thing" in your business. If you have a good database
design, your business objects will probably look a lot like your
database tables (but will by no means be one-for-one).
The second is the one that Microsoft seems to be pushing: have Visual
Studio generate strongly typed DataSets from the database tables, then
inherit from the resulting (automatically generated) classes and add
your business rules as additional methods or overrides of the methods /
properties that were generated by Visual Studio. I haven't tried this
myself, but it seems to be the approach that MS is pushing.
Whatever you do, whether you hand-tool your own business layer, or use
the Microsoft approach, or use some other tool to build your business
layer, the important thing is to keep business rules out of your Forms
/ Web forms code. User interface code has no business knowing that the
reason this control over here is disabled is that "orange widgets don't
have packaging" or some such thing. That sort of information belongs in
your business layer, and, as Joanna points out, filling your Forms
event handlers with business rules quickly becomes an enormous
spaghetti mess.
Joanna Carter (TeamB) wrote: "Patrick B" <ne*******@devzoo.com> a écrit dans le message de news:
#R**************@TK2MSFTNGP10.phx.gbl...A "business object" is just a class that represents a real entity with
which you work. For example, if you work with customers and orders, then
you might have a Customer class and an Order class.
Check out the following link:
http://www.mygenerationsoftware.com/...s/dOOdads.aspx
The tool from MyGeneration can create C# code for business objects
automatically from tables in a database. Then you can bind controls in
your gui to that.
As useful as you might think such a tool is, I would seriously advise
against using database design as the foundation for class design. There are
several patterns, like foreign keys, that are not necessarily correct in OO
world.
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.
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.
e.g.
Database
========
SalesOrder
ID
Date
CustomerID (FK)
Tax
Total
OrderLine
ID
OrderID (FK)
Quantity
ProductID (FK)
LineValue
Classes
=======
SalesOrder
ID (unique ID held internally, not used in client code, just by storage)
Date
Customer (object not ID)
Lines (composite list only accessed through AddItem method on this class)
Tax
Total
OrderLine
ID (unique ID held internally, not used in client code, just by storage)
Quantity
Product (object not ID)
LineValue
It is usually the job of a mapping layer to maintain the solution to this
apparent mismatch between the Object Layer and the Database.
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.
A 'SalesOrder' will not be a different entity in your world than in
mine. There is no mismatch, it's just semantics.
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.
Deleting 1000 objects from the database, same thing.
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.
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#)
------------------------------------------------------------------------
Joanna Carter (TeamB) wrote: "MyGeneration" <My**********@discussions.microsoft.com> a écrit dans le
message de news: D8**********************************@microsoft.com...Your application in the end exists only to manipulate data, the data is the
application, everything line of code your write exits to flip a bit or save a
value in your database. Starting with the database and working from the
ground up is an excellent and proven way to write an application, and is how
most do it.
Database design used to be the standard, well-proven basis for non-OO
applpications; I know, I was weaned on Logical Data Structure diagrams.
But where do you put the code that manipulates the data ?
Please don't tell me you use data-aware controls directly connected to
database tables and write the code in event handletrs on the forms!! :-))
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)
- 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)
the first two are perfectly placable inside entities, the 3rd isn't, as
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
Not all data in an application is stored in a database. In a well designed
OO application you may well have hundreds of classes that have nothing to do
with *stored* data.
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.
This isn't science fiction, this is reality for system designers for
over 20 years. I know what the domain model is, and your reasoning comes
from it, but don't bring it as if before the domain model software
developers were just doing unstructured things without any theoretical
basis. On teh contrary.
The frameworks I have written to support my applications contain around 300
classes and interfaces.
that's nice, now let's look at what you have to do when I present you
an enterprise db with 1300 tables.
There is the Value Type Framework that gives me more metadata about my
business objects and their properties.
There is the Object Persistence Framework that allows me to write OO code
that knows nothing about databases because the OPF translates business
objects to/from database tables, generating SQL on the fly. I only ever use
one Query component, one Transaction component and on database component in
my entire application and frameworks combined.
So do I, though I do start from the relational model.
There is the MVP framework that allows me to replace my UIs without having
to change any of the code in either my business objects or the applications
that use them.
MVP framework, hmm. ;)
But what you describe here is just normal n-tier goodness: you write a
BL layer which acts on its own, so you can place on top of it a gui tier
which can work on its own, consuming the services of the bl tier...
that's also ancient tech, and not OO related
How would I extract those classes and interfaces from a database ?
You have a system design, abstracted. That design learns you about an
entity 'Customer'. That's an abstract thing, it's build up from
attributes, like 'CustomerID', 'CompanyName' etc.. You know, the basic
CS stuff.
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.
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.
What about those applications that don't use databases ?
well, what about them? Once you have your database design you can then use that very useful AND
accurate data to generate the classes that represent that data.
MyGeneration does exactly that.
How does your software translate the Sales Order example I gave ?
Well, how does your software represent objectified relationships which
represent m:n relations?
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.
It's all about technical solutions for the data-access problem,
something which only exists in teh technical problem space. It doesn't
exist in the abstract functional problem space. There are different
solutions to that technical problem, and the one which fits with your
way of work depends on how you want to work, as there is no right or
wrong here. I wrote an article about that some time ago, you can find it
here: http://weblogs.asp.net/fbouma/archiv...09/240225.aspx
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#)
------------------------------------------------------------------------
Frans,
I am not a theoretical who likes to describes the why's.
However, in this kind of discussions I miss forever what is in Dutch called
the "Goederenstroom en Geldstroom".
Can you give me the correct English names for those two.
Thanks in advance.
Cor
Ignacio Machin ( .NET/ C# MVP ) wrote: "MyGeneration" <My**********@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com...Starting with the database and working from the
ground up is an excellent and proven way to write an application, and is
how
most do it.
Totally agreed with you, The DB design helps you identify the potentials
entities involved in the business layer and the relationships among them,
Now where I disagree with you is that you should take into account that the
requirements of the business layer is different that those of the DB layer,
ie you don;t have a third normal form for business layer that can assure you
have a good design.
The relationship among buss. entities are differents and others patterns
exists for this layer.
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. Other people will say: no, the concept of the SalesOrder as
a business object doesn't really exist. I just have entities: Customer,
Order, OrderLine, Address, Employee and these have relations, but the
behavior applied to them is only in a runtime context, e.g. the context
which process the SalesOrder, and that logic then thus works with all
these entities (in a graph or separately).
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.
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#)
------------------------------------------------------------------------
Frans,
Other people will say: no, the concept of the SalesOrder as a business
object doesn't really exist.
It is a legal document needed for every transaction.
In most however in our country for sure very much embedded by law (BW).
Without it not any process in a bussiness situation can exist in our
country.
The object in whatever way it is constructed represents that in the
information system.
Just my thought,
Cor
On Sat, 26 Feb 2005 12:01:42 +0100, "Cor Ligthert"
<no************@planet.nl> wrote: Frans,
I am not a theoretical who likes to describes the why's.
However, in this kind of discussions I miss forever what is in Dutch called
the "Goederenstroom en Geldstroom".
Can you give me the correct English names for those two.
Thanks in advance.
Cor
Are these close ?
Goederenstroom: Flow of goods
Geldstroom: flow of funds
Michael Hughes - Silverton, Oregon http://wou.ath.cx/Trivia http://wou.ath.cx/AmateurRadio
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).
Cor
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> 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.
*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.
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.
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.
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.
A 'SalesOrder' will not be a different entity in your world than in
mine. There is no mismatch, it's just semantics.
The mismatch is not in the Model, it is in the implementation of the Model.
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 ??
The SQL generated by my OPF is identical to that required to store entities
to tables without OO.
Deleting 1000 objects from the database, same thing.
With an OPF, same SQL, same thing.
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 ? :-))
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.
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 ?
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 :-)
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> 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.
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 :-)
Other people will say: no, the concept of the SalesOrder as
a business object doesn't really exist. I just have entities: Customer,
Order, OrderLine, Address, Employee and these have relations, but the
behavior applied to them is only in a runtime context, e.g. the context
which process the SalesOrder, and that logic then thus works with all
these entities (in a graph or separately).
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 ?
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.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: e3*************@TK2MSFTNGP15.phx.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
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
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 invoiceprocesser 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.
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#)
------------------------------------------------------------------------
Joanna Carter (TeamB) wrote: "Frans Bouma [C# MVP]" <pe******************@xs4all.nl> 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#)
------------------------------------------------------------------------
Joanna Carter (TeamB) wrote: "Frans Bouma [C# MVP]" <pe******************@xs4all.nl> 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#)
------------------------------------------------------------------------
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.
stork <tb******@mightyware.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.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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!
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.
stork <tb******@mightyware.com> wrote: 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!
But I think that's at least partly *because* it's declarative.
Declarations don't sit well with how humans think about step-by-step
logic. 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.
That's pretty reasonable - and a lot of behavioural stuff in 3 is also
best described imperatively, IMO. 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.
So it'll be 15 years before OOP will "go to the dustbin of history"? I
guess we have a different idea of "soon". I think it's quite possible
that OOP will have been overtaken by then - and it'll have had a pretty
good run by computing standards at that stage. I doubt that it'll go to
a purely declarative model though.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
TJB replied to: But I think that's at least partly *because* it's declarative.
Declarations don't sit well with how humans think about step-by-step
logic.
I'd disagree largely because Excel is a declarative system, at least
with respect to formula in cells, and most people prefer to think in
those terms rather than with step by step logic.
That's pretty reasonable - and a lot of behavioural stuff in 3 is
also best described imperatively, IMO.
LOL. :-)
So it'll be 15 years before OOP will "go to the dustbin of history"?
I guess we have a different idea of "soon". I think it's quite possible
that OOP will have been overtaken by then - and it'll have had a
pretty good run by computing standards at that stage. I doubt that it'll go
to a purely declarative model though.
It probably won't be purely declarative because even in declarative
worlds you have to have a mechanism for adding or subtracting rules
from the system and those are imperative things. Or are they?
But, whatever it is, it will still have braces to indicate logical
groupings, and it will look like some C derived language.
Jon Skeet [C# MVP] wrote: stork <tb******@mightyware.com> wrote:
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!
But I think that's at least partly *because* it's declarative.
Declarations don't sit well with how humans think about step-by-step
logic.
No, it's because how normal programmers think: in if, for and switch
statements (or equivalents). XSLT is a functional language, like
miranda, haskell and the like and uses pattern matching, just like for
example miranda does. What I find sad is that XSLT does have these
imperative-esk constructs like a loop, which is completely not fitting
into the language direction. I find XSLT pretty elegant, but indeed it
does take a step back and realizing you're working with a functional
language. Once that's done, (the same 'click' you need to fully
understand prolog IMHO), XSLT is easy.
FB
Frans,
When I saw XSLT the first time I tried it.
And than I decided that the load.Doc and JavaScript did cost me a quarter of
the time and I could do ten times as much with JavaScript to transform a XML
file.
I found it a real enduser solution (generator). I did not take one look
anymore to it and that is a while ago.
(Not discussing that it maybe can be a good tool, my previous text explain
why I stopped with it evaluting it)
:-)
Cor
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: O5**************@TK2MSFTNGP12.phx.gbl...
I'm not even going to continue arguing the OO versus RDB case. I have
previously met RDB zealots who think the world and its problems can all be
solved with RDBs and that OO is a corruption of the one true faith. :-)
You are certainly welcome to your views, but I have found differently.
I am in the business of saving time and effort for software developers and
their companies; every company I have introduced OO frameworks which merely
use RDBs for storage instead of the design of their applications has found
the effort required to create applications diminishes in proportion to the
quality of the OO model instead of their old ways of using the RDB as the
source of design.
YMMV, but that is usually down to the level of competence in good OO design.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Hey,
if you're interested, read the following: http://www.asplications.com.au/GenieWhitePaper.pdf. It is most definitely
on your side of the virtues of Object Oriented thinking debate.
"Joanna Carter (TeamB)" <jo*****@nospamforme.com> wrote in message
news:ez**************@TK2MSFTNGP15.phx.gbl... "Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: O5**************@TK2MSFTNGP12.phx.gbl...
I'm not even going to continue arguing the OO versus RDB case. I have
previously met RDB zealots who think the world and its problems can all be
solved with RDBs and that OO is a corruption of the one true faith. :-)
You are certainly welcome to your views, but I have found differently.
I am in the business of saving time and effort for software developers and
their companies; every company I have introduced OO frameworks which
merely use RDBs for storage instead of the design of their applications has found
the effort required to create applications diminishes in proportion to the
quality of the OO model instead of their old ways of using the RDB as the
source of design.
YMMV, but that is usually down to the level of competence in good OO
design.
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
"Radek Cerny" <ra*********@asplications.nospam.com.au> a écrit dans le
message de news: u8**************@TK2MSFTNGP12.phx.gbl... if you're interested, read the following:
http://www.asplications.com.au/GenieWhitePaper.pdf. It is most definitely
on your side of the virtues of Object Oriented thinking debate.
Interesting, it certainly is on the lines of what I have been doing for
years now :-)
Joanna
--
Joanna Carter
Consultant Software Engineer
Joanna Carter (TeamB) wrote: "Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: O5**************@TK2MSFTNGP12.phx.gbl...
I'm not even going to continue arguing the OO versus RDB case. I have
previously met RDB zealots who think the world and its problems can all be
solved with RDBs and that OO is a corruption of the one true faith. :-)
Oh, so now I'm an RDB zealot and I hate OO? geezz...
I am in the business of saving time and effort for software developers and
their companies;
So do I, WITH OO and O/R mapping, but you must have missed that part.
every company I have introduced OO frameworks which merely
use RDBs for storage instead of the design of their applications has found
the effort required to create applications diminishes in proportion to the
quality of the OO model instead of their old ways of using the RDB as the
source of design.
That's great, but I don't see why an RDBMS is suddely useless crap and
should be ignored for the most part. You're using OODB's too?
YMMV, but that is usually down to the level of competence in good OO design.
hahaha, I can only laugh at such a silly implication of the quality of
the software I produce. Come on, you can do better than that.
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#)
------------------------------------------------------------------------
I totally agree with Frans on this, I have never understood why folks say
that Relational Databases and OO design techniques do not align? I think they
align perfectly and the "methods" are clamped on at run time to implement the
business logic, this argument just does not hold water, it never has at least
for me.
Anyway, There are a lot of very good tools out there to help folks create
business objects or map data entities on top of relational databases, every
time somebody downloads our product or somebody elses and get's turned on to
generating these entities we nudge the development community a tiny step
ahead. We work smarter and build better apps.
Mike Griffin
MyGeneration Software http://www.mygenerationsoftware.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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. ...
|
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...
|
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.....
|
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;
|
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...
|
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...
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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...
|
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...
|
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...
|
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,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
