We just finished to deliver our first big .NET system with a 4-Layered Architecture and domain objects. The proof-of-concepts is done also for big systems.
Because we use a 4-Layered Architecture, the same business rules describe in the Task Layer (or Service Layer, as you wish) are applied to both the desktop and the web versions of the application.
NHibernate has also proven its value showing that it has enough performance for any kind of systems. I am anxious to start building other layered object-oriented systems like this.
2006-11-09
Delphi for OO Programmers
I just came from a presentation about Borland products.
One of the speakers were showing a piece of Delphi code to explain his idea about object oriented programming and multi-tiered application for Delphi.
The Delphi syntax for declaring classes is very bad. Instead of using a syntax similar to what we can find in C++, Java or C# there were strange reserved words. For declaring a Person class, one must code:
To inherit from a Person it should be something like:
After that in the beginning, the speaker said the "some people" say that OO programming is about, for example, creating a Person class, adding methods to manipulate data, using the instance to perform business logic and then saving to the database. He said that is not the only way and this is just the Java way to build OO systems.
At this point I turned off my attention from the presentation for a while and I started wondering if there are other ways to build OO systems.
What he was calling OO programming was a class with lots of static methods responsible for executing a piece of the system. There was a method for inserting a person, erasing a person, calculating a salary, inserting a document, etc.
Well I would say this is a Service Class but that doesn't mean that this is a OO system. A lot of people say that because they have declared a class or interface they can assume they are programming using the OO paradigm. A paradigm is not only using objects but a way of thinking and an object oriented system is one that was designed as a collection of objects exchanging information between them by using methods.
I have heard a lot of people saying that and it is almost rare to find someone that really understans what OO means. At least here where I live in Brazil. I don't think the programmers must know about OO paradigm but they must admit when they don't know about a subject and should give the adequate name to the methodology they are working with. In that case above of the Delphi guy, I would say procedural paradigm.
I also got to the conclusion that a programming language like Delphi was not meant to use OO although it supports this paradigm.
One of the speakers were showing a piece of Delphi code to explain his idea about object oriented programming and multi-tiered application for Delphi.
The Delphi syntax for declaring classes is very bad. Instead of using a syntax similar to what we can find in C++, Java or C# there were strange reserved words. For declaring a Person class, one must code:
type Person = class
private
name : string;
end;
end;
To inherit from a Person it should be something like:
type SpecialPerson = class(Person)
......
end;
After that in the beginning, the speaker said the "some people" say that OO programming is about, for example, creating a Person class, adding methods to manipulate data, using the instance to perform business logic and then saving to the database. He said that is not the only way and this is just the Java way to build OO systems.
At this point I turned off my attention from the presentation for a while and I started wondering if there are other ways to build OO systems.
What he was calling OO programming was a class with lots of static methods responsible for executing a piece of the system. There was a method for inserting a person, erasing a person, calculating a salary, inserting a document, etc.
Well I would say this is a Service Class but that doesn't mean that this is a OO system. A lot of people say that because they have declared a class or interface they can assume they are programming using the OO paradigm. A paradigm is not only using objects but a way of thinking and an object oriented system is one that was designed as a collection of objects exchanging information between them by using methods.
I have heard a lot of people saying that and it is almost rare to find someone that really understans what OO means. At least here where I live in Brazil. I don't think the programmers must know about OO paradigm but they must admit when they don't know about a subject and should give the adequate name to the methodology they are working with. In that case above of the Delphi guy, I would say procedural paradigm.
I also got to the conclusion that a programming language like Delphi was not meant to use OO although it supports this paradigm.
2006-10-28
OO Paradigm Popularity
As far as I know OO has existed since the 70's. For a long time, OO was mainly used for academic projects. In the meantime relational databases gained popularity between comercial computer systems and so the relational model.
The relational model has also evolved gained popularity since it presented a concrete solution to the problem of how to store data of a business model.
With the rise of Java Programming Language, OO became much popular since it motivates the programmer to use this paradigm.
One of the most important characteristics of the OO paradigm for enterprise applications is that the data and the functional aspects of a business model could be abstracted. Thus OO paradigm offers a higher level of abstraction compared to the relational model however that didnn't turn itself into a practical advantage for comercial system.
Relational Databases are responsible for almost all data storage in computer systems while OO Databases ( not talking about Object-Relational Databases like Oracle ) are not sufficiently mature yet and although it was easier to build more complex software an old problem still persisted which is the OO paradigm and the relational model mistmatch problem deeply explored by Scott W Ambler.
( http://www.agiledata.org/essays/impedanceMismatch.html )
This impedance mismatch use to consume a lot of time from OO programmers. For example, a line in a Person table in a relational model is represented as a Person object. Before in order to do that OO programmers had to program a persistence layer by hand. Besides time consuming it was also a complex task. These reasons were enough to put OO away from the comercial software market for several years.
The Object-Relational-Mapping Tools (ORM Tools ) addressed this issue more productive way. With these tools the columns of a table in the relational model were mapped to an attribute in a class in the OO model. These mappings can be done in a XML file, in a separate class or by using annotations. The most stable and well-documented so far is Hibernate.
( www.hibernate.org )
Whatever these mappings are described these tools made it possible to use OO in Enterprise Applications Projects. It was not necessary to spend so long time to implement object persistence and it was also possible to use OO in legacy relational databases.
There are even tools that generate the class code in Java or .NET and the mapping code from the database schema like MyGeneration.
( http://www.mygenerationsoftware.com/portal/default.aspx )
Interestingly there lot of articles out there saying that there is no evidence proving that the OO approach is a an advantage over the relational programming and not a long time ago some authors used to say that OO in Enterprise Applications was something impossible.
In my opnion OO offers advantage in a long term since the business model is gradually represented with a higher level of abstraction.
The relational model has also evolved gained popularity since it presented a concrete solution to the problem of how to store data of a business model.
With the rise of Java Programming Language, OO became much popular since it motivates the programmer to use this paradigm.
One of the most important characteristics of the OO paradigm for enterprise applications is that the data and the functional aspects of a business model could be abstracted. Thus OO paradigm offers a higher level of abstraction compared to the relational model however that didnn't turn itself into a practical advantage for comercial system.
Relational Databases are responsible for almost all data storage in computer systems while OO Databases ( not talking about Object-Relational Databases like Oracle ) are not sufficiently mature yet and although it was easier to build more complex software an old problem still persisted which is the OO paradigm and the relational model mistmatch problem deeply explored by Scott W Ambler.
( http://www.agiledata.org/essays/impedanceMismatch.html )
This impedance mismatch use to consume a lot of time from OO programmers. For example, a line in a Person table in a relational model is represented as a Person object. Before in order to do that OO programmers had to program a persistence layer by hand. Besides time consuming it was also a complex task. These reasons were enough to put OO away from the comercial software market for several years.
The Object-Relational-Mapping Tools (ORM Tools ) addressed this issue more productive way. With these tools the columns of a table in the relational model were mapped to an attribute in a class in the OO model. These mappings can be done in a XML file, in a separate class or by using annotations. The most stable and well-documented so far is Hibernate.
( www.hibernate.org )
Whatever these mappings are described these tools made it possible to use OO in Enterprise Applications Projects. It was not necessary to spend so long time to implement object persistence and it was also possible to use OO in legacy relational databases.
There are even tools that generate the class code in Java or .NET and the mapping code from the database schema like MyGeneration.
( http://www.mygenerationsoftware.com/portal/default.aspx )
Interestingly there lot of articles out there saying that there is no evidence proving that the OO approach is a an advantage over the relational programming and not a long time ago some authors used to say that OO in Enterprise Applications was something impossible.
In my opnion OO offers advantage in a long term since the business model is gradually represented with a higher level of abstraction.
Subscribe to:
Posts (Atom)