|
I enjoy programming...
|
|
|
|
|
Hello,
Good article. Keep it up. I've no experience in working with enterprise applications. But the review can be a bit more in depth. Like what the interesting chapters/sections you've seen across the book, which you really feel like exclusive. The pros and cons. etc.
Once again good work. Keep writing.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Good article, great for your frist. TO make it better you might want to add some images to show the patterns.
cheers,
Donsw
My Recent Article : Optimistic Concurrency with C# using the IOC and DI Design Patterns
|
|
|
|
|
Hi there,
I am eager to read your part 2 and 3 and whats your view of MVC?
thanks
|
|
|
|
|
Member 2910018 wrote: Hi there,
I am eager to read your part 2 and 3 and whats your view of MVC?
thanks
yes - ditto... c'mon get a move on with it
|
|
|
|
|
Good job, your article introduced the concept behind this the book brilliantly.
I really hope I can get as much benefit from the book as you clearly have...
Ian
|
|
|
|
|
Hi Levi,
I have read your review of PEAA on Code Project. Well, it seems interesting. One general comment that I have is that, well, patterns are the result of real life experiences and overtime some of the pattern might seem quit similar even with slight differences (please note that this is just a general thing). After reading different pattern proposals and architecture methodologies, what I really want to know is , in your view, how PEAA is different from Core J2EE patterns?
To my understanding even though J2EE patterns in detail is using J2EE as examples, the concept can be applied technology independent. To me, this can be applied to the patterns proposed by Microsoft for .NET framework.
So when you have studies PEAA, did you feel to much of different between these patterns and Core J2EE patterns?
I will appreciate your comments.
Thanks,
Sasan
|
|
|
|
|
I'm kind of relieved to know that I'm not alone in trying to apply the patterns in POEAA. I'll be very interested in discussing my experience with you since we'll most likely face similar challenges.
I'm also in the process of applying the process to applications being developed in my firm. This is probably the 3rd time around trying to properly apply the patterns and I came to some of the same realisations. Unfortunately the first two iterations were in VB6 which practically undermined all I had set out to achieve. After the first application I developed trying to apply the patterns I realised as you have that the "Client Application Code" was to closely tied to the Domain Objects and as a result would make the application very brittle if anything in the domain objects change.
In this present iteration I am also applying the Service Layer or Business Facade pattern to address this problem. Actually I arrived at this approach because of two driving forces. One was the need to support some kind of remote usage of the domain layer through web services or some other. The second driving force was the need to reduce the coupling of the Client Application code to the domain layer.
One of the biggest issues I face is deciding what goes into the facade and what should go into the domain objects. The general rule is put domain rules into the domain layer and application code in the facade. The problem is, what exactly is domain behaviour and what is application behaviour and how exactly can you tell the difference? Should domain objects always create other domain objects or should the application layer also create some? These sort of problems slow me down all the time.
Coupled with this is my desire to apply other patterns like mappers or the repository to abstract data access.
I think most of these problems will be solved by seeing a simple but realistic example of how these patterns have been used in practice. I believe this is usually the gap that all book readers always try to bridge. As good as the snippets of code in the book are, the continuous thread of linking all of these techniques into one seamless application gets lost somewhere inbetween and you find yourself jumping from section to section trying to string them together.
This is getting quite long hope you all don't mind but I'm just pouring all this stuff out.
How about the Unit Of Work, a fantastic pattern which I have used in the past but I'm now trying to figure out where it fits in once the facade is in place.
Other minor complications include what data representation should the facades use? Should they use datasets only which microsoft seems to advocate or should you create custom data transfer objects since passing the objects themselves over the wire for remote invocations is out of the question. This being as it may, I would like my service layer to use real business objects so I can work directly with them in an inprocess situation like a single machine rich client or a web server running the business layer in process. Then I would want to be able to add on a remote facade which can use data sets or primitive data types at its edges to return or receive any data. Examples from microsoft code seem to use the same data sets received from the data access layer as the transport between the facade and its clients. Is this a good thing or should one create another set of data sets for the facades.
I'll just end here for now so as not to bore you but problems still abound.
When are your other articles coming out? Hurry up please...
Finally has anyone read and used the Streamlined Object Modeling methods in building their domain layer? Like to discuss???
|
|
|
|
|
Hi Levi,
Article is too nice. You had given it in plain english, so novice or new designers can also follow your article well. Hats off to you effort. Please take my words as suggestion:
1. you can improve by providing relevant diagrams. Usually it will give bigger picture to audience and easily they can absorb.
2. can take a case study type and analysis and provide an solution type. It will impress and also help other to understand, what's the linkage between design, development and its importance.
That's up!! If time and environment permits, you can do this in your forth coming article or your POC(Proof of Concept).
Deva Gnanam .J
Software Consultant, Infosys Technologies, Hyderabad, India
|
|
|
|
|
In your review you begin by talking about the desire to have a framework that is easily modified to suit new "clients". Later you talk about removing "client" code from your domain objects. In the latter case are you talking about UI code rather than code related to your company's "client"; e.g., client specific business logic?
I enjoyed the article, particularly since I'm in the process of rereading this book at the moment. I'm curious to know how you found his intro to MVC. I found it a bit confusing for reasons similar to the above. Notice how he starts off talking about "view" and then (without warning) transitions to the term "presentation" instead. I'm of course assuming the two terms are interchangeable. Is that how you read it?
I look forward to your next installment.
Regards,
Bill
Bill Cohagan
|
|
|
|
|
Bill Cohagan wrote: In the latter case are you talking about UI code rather than code related to your company's "client"; e.g., client specific business logic?
great questions, and you are absolutly correct in pointing out that i was not clear when talking about "client".
In both instances i am referring to the "clients" of our company. When our framework was initially created, it was actually not created with the mindset of being reused. It was not until we were 80% done with development of that "project" that we realized we were on the doorstep of making our (IT) lives much easier. Once this realization occurred, that's when we started implementing a Service Layer, and extracting out code specific to that one client into its own service layer.
I don't want to give anything away from my next articles, so I am going to have to pass on your questions regarding the Model View Controller. Part 3 of this series will be spent entirely on the Web Presentation Patterns section.
I hope this helps to answer your questions and thanks again for taking the time to read this article. I hope that dialog like this will help others build better applications now and in the future!
Levi Rosol
Blog By Levi[^]
-- modified at 10:27 Thursday 8th December, 2005
|
|
|
|
|
Levi
Thanks for the clarification. So, as I now understand it your domain model is independent of client and is thus your framework is invariant across clients down to the domain level. I was reading the article with a different mindset because I'm presently using a framework that does not assume anything about the domain model (which in our case will indeed vary from client to client.)
I'll keep an eye out for your followup articles and look forward to your comments on the MVC section(s).
Regards,
Bill
Bill Cohagan
|
|
|
|
|
I've just ordered this, conatct the author for yourr commission!
|
|
|
|
|
L Hills wrote: Nice review
great! now just rate this article accordingly
Levi Rosol
Blog By Levi[^]
|
|
|
|
|
I have submitted a revision and the image should be fixed soon.
Levi Rosol
Blog By Levi[^]
|
|
|
|
|
ok, the image has been fixed.
Happy reading!!
Levi Rosol
Blog By Levi[^]
|
|
|
|
|
Hi thanks for this article.
Do you happen to have some example in a solution I can download on how to pass data between layers and therefore see how it is actually applied rather than the theoretical approach?
Thanks A lot
vbinfo@devnet247.com
|
|
|
|
|
vbinfo wrote: Do you happen to have some example in a solution I can download on how to pass data between layers and therefore see how it is actually applied rather than the theoretical approach?
I don't. however, that's a great idea that I may include with my next two articles. It won't be anything uber special, but I think I could whip something up.
Also, in the book are some great examples for each of the patterns discussed. The code examples are in Java and C#, and are very easy to read even if you are not a Java or C# developer.
Thanks again for reading this article!
Levi
Levi Rosol
Blog By Levi[^]
-- modified at 9:36 Thursday 1st December, 2005
|
|
|
|
|
thank you for this job
drvb1983@yahoo.com
|
|
|
|