|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 20
Messages: 20
Messages: 20
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Domain Objects Persistence Pattern for .NET
Iqbal M. Khan describes a pattern in which persistence logic is abstracted away from Domain Objects, including C# source code for an implementation of the pattern.If domain objects are not separated from the rest of the application, we end up with duplication of code everywhere. Similarly, if domain objects are not separated from the persistence code, we face situations where any subsystem using the domain objects also knows and depends on the persistence objects. And, any change in persistence objects affects the entire application, hence a bad design. Read Domain Objects Persistence Pattern for .NET
|
|
|
Message #180348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DataMapper
I don't believe that the author was attempting an original piece with this as much as a description of what others are doing. Patterns are by definition based on what has already been done.
The question I would ask is how useful is this pattern, or this implementation, compared to others?
|
|
|
Message #180373
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DataMapper
My exception isn't really that he's claiming he invented this construct--it's more that he should use pre-existing name for this pattern rather than invent a new one.
The only place this pattern is called the "Domain Objects Persistence Pattern" seems to be in the various copies of this article that have been published.
http://tinyurl.com/9asjx
http://tinyurl.com/bsos7
http://tinyurl.com/e2nyq
http://tinyurl.com/7kawt
http://tinyurl.com/dj9eb
On the other hand, the Data Mapper pattern is a pre-existing name given to this specific idiom. One of the main benefits of design patterns is creating a common vocabulary that architects and developers can use to have more fluid discussions.
If you say a Singleton, I know exactly what you mean. If you call it a Singularly Constrained Instance Existence Pattern, all I'm going to do is wonder if you mean a Singleton. So in addition to the benefit of using proven idioms that have stood the test of time, being able to have a common set of semantics regarding these idioms is another significant benefit of patterns.
Is Data Mapper useful? Sure it is. Data Mapper vs. ActiveRecord (http://tinyurl.com/b9z2q) tends to be the typical design tradeoff between convenience and loose coupling. Most of the common persistence frameworks structure theire api or generated code in one of these two data access primitives.
A compare/contrast of the mainstream ORM/persistence frameworks would probably make for an interesting read, either that or a more concrete illustration of the subject pattern so that people learning from the article can go from concept to working example in a sitting.
|
|
|
Message #180459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Objects Persistence Pattern for .NET
uhhh...an the point is?
There's a few sections missing from the pattern description that would be nice to see (not that you always need them all) like Consequences, AKA, Known Uses, Related Patterns, etc.
...and I see nothing new here besides the name...
|
|
|
Message #180461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Grog Object Model
Grog call model Grom for short.
Grog make up Grom by self.
Grog take SQL and put in seperate file.
Grom Good.
Grog scientist.
|
|
|
Message #180814
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Objects Persistence Pattern for .NET Article Quality
My opinion is that the subject is important to be discussed, since the majority of enterprise applications are using some kind of datastore, but the quality of this article is low (probably the editor is in holiday this time of the year).
First this subject is already well documented, even so if you decide to discuss it (which I think is a good thing) you should try to cover a large spectrum of sources and the article to be more like an analisys.
Also what the author propose here is well suited for small applications with a few tables and with no changing software requirements, I'd like to ask what you are going to do if you have behind more than 20 tables? for example 200 tables? you are going to hire a bunch of junior to develop, maintain and test the objects? plus effort for persistance data.
Maybe somebody decide to make an analisys and comparison between existing articles, patterns and case studies, because I repeat I think the subject is good and worth to be discussed it.
|
|
|
Message #180819
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not so bad
I agree with all of you that what the author writes about is the well know topic of the DAL, DAO, DataModel, DataMapper, HEYLTNI (HowEver You Like To Name It :-)).
But I think that it's all "zipped" in short article good to understand in a few lines why and how to implement it, without the need to understand sequence diagram or class diagram and so on.
Simo
|
|
|
Message #180823
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Repositories
An improved version of this pattern (Repository) can be found in Eric Evans book titled Domain Driven Design.
Basically it says that persistence should be refactored out to a separate repository class that behaves much like a collection class, thus separating the persistence logic from the business class. Steve Eichert discusses the pattern in detail on his blog, and provides some useful enhancements for aggregated objects (http://steve.emxsoftware.com/Domain+Driven+Design/DDD+Aggregates++Repositories).
|
|
|
Message #180854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't bother mapping, go for an open source OODBMS for .NET
Have a look at the open source OODBMS "db4o" at http://www.db4o.com
Mapping a three dimensional object design to a flat, two dimensional, relational database is a waste of time and no longer needed. Actually, it’s no longer needed for many years now.
db4o supports .NET and Java. Awesome stuff if you asked me. In my 15 years of professional software engineering, a true OODBMS can save you at least 50% of development time and, more importantly, 50% of support, maintenance cost, time and headaches over the live span of an application until it is retired.
I’m always amazed how narrow minded we have become as developers and forced into this outdated, droned, “Borg”-like thinking that we should design our apps based on a database schema. This used to be funny, but, sadly, it’s become a sorry cancer in our profession.
I understand that for existing applications or applications that we inherited one way or another, a good Object Relational Mapping layer (ORM) is a compromise and the way to go until you have a chance to change the architecture.
I can go on forever; but, check out db4o. It’s very promising. I’m using it in one of my applications with C#.
|
|
|
Message #181017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
gateway pattern in fowler's book
there is a product called RapTier that generates the factory classes in C# or VB code from reading the database schema. check the sample code from reading the Northwind database at www.sharppower.com
|
|
|
Message #181045
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Such a Pity...
Is there something new in this article? Posted in August 4, 2005 - it would have been nicer if it was 1995 or earlier! I don't know why it came in the newsletter, because of a catchy caption?
|
|
|
Message #181642
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Factory vs. Mapping Objets
For me, a factory should contain methods that create objects. The factory should create objects of type Customer. A factory shouldn't be used to remove or update objects.
for example ...
public class CustomerFactory : ICustomerFactory
{
Customer CreateCustomerFromFile() { /* Implement here */ }
Customer CreateCustomerFromDatabase() { /* Implement here */ }
}
The Old CustomerFactory class should be renamed CustomerMapper or CustomerManager. Not because of a fancy pattern but because the class is an interface between the Customer Bean and the Database.
|
|
|
Message #182566
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pointless??
Err...
It's this pointlessly simple. You have to throw away your object as soon as you've used it. And if 2 threads open "the same" object updates are not propagated....
This just looks like a toy example or a subset of a bigger pattern as mentioned above...
|
|
|
Message #182773
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Factory pattern
A factory Creates objects, it doesn't persist nor delete objects.
This kind of confusing articles annulates the work to try to standarize patterns and give us developers a common vacabulary.
|
|
|
Message #184237
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How is it different than DAO pattern?
I've read this article and to my surprise realized that it is DAO pattern author is talking about (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html)
Why did the author change the pattern name to "Domain Objects Persistence"?
Is he trying to "reinvent the wheel" here?
I think regardless of the platform Java, C++ or C# the patterns are stay the same. It is strange that by using another programming language, authors can justify name change of the existing and well-known patterns...
|
|
|
Message #206646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DAO and Business Logic
As I could read here I should separate business logic, that should be in a business class from a DAO class that implements data access methods. Business classes should not be aware of DAO classes or any other data source logic.
However sometimes it is not so clear. We have several classes here where certain methods implement both data and business logic.
Example:
[ Client ] ----> * [ DocumentHistory ] ---> 1 [ Document ]
A Client has several Documents in time. DocumentHistory stores the initial date and final date that a Document belonged to Client. ( Just like an aggregate table )
A Client has a method GetDocument(date) which returns the current Documents of a Client based on the passed datetime.
In order to do that, I should bring all DocumentHistory where initial date <= date and final date > date. For each DocumentHistory that obeys the criteria above I can get its Document and finally return the Document list.
The problem is how can I implement a method like this in Client without referencing its ClientDAO methods ?
|
|
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(33 comments,
last posted
July 13, 2009)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
