[not considered good OOAD to use verbs] You're right, of course. My hastily written online example was a poorly chosen name. Rather, I would use something like "OrderManager", which would, in turn, have methods like "PrepareOrder", "GetOrder", "CheckOrderStatus",
etc.
Well, Thomas, I guess we're going to have to agree to disagree here. Because for one thing, my goal is NOT OO nirvana. So I am not claiming that my design is "pure", because I learned some time back that, although pure OO is soothing to the intellect, it is
not an essential ingredient of, nor does it ensure the success of, n-tier, web based app development. Nor does its absence doom a project to abject failure. I use OO techniques where appropriate, and I use "component" techniques at other times. The two are
NOT the same. So I am not presening it as a "pure" OO method. As to taking a course on OOAD, I'll recommend an excellent one -- the one I taught internally at our company about 10 years ago. And although I am not going to try to defend it against all arguments,
I submit that a design that puts the use cases at the heart of the infrastructure of the application is every bit as "object oriented", and valid, as a design that relies on object-relational techniques. I think that all too often some of the OO things that
people are striving for become straight jackets to them. And worse, they are trying to apply concepts that were conceived of in the days of rich-desktop client-server apps to the world of n-tier, browser-based web applications where today's client is a web
browser, but tomorrow's may be a distant server talking to us through a web service or a hand-held cell phone. Now I'm not claiming to be a Bjarne Stroustrup, or a Grady Booch, or Scott Meyers, or any of those kinds. I'm just a fellow who has "done objects"
since before Visual C++, and who has seen a lot of OO projects through from inception through implementation, production, maintenance and eventual retirement. That's one of the advantages of staying with the same very big company (very big == 100,000+ workstations
on our intranet) --you get to see a LOT of full lifecycles, both your own and other people's. And I'm here to tell you that what matters a whole lot more over a lifecycle than the "purity" of the design in terms of the tool or language, or approach used is
how well the design groked the goals that the app was supposed to achieve, both immediate and future. And in that mix, I have seen some of the "coolest" Object designs utterly fail, and some of the most bastardized designs succeed beyond expectations. Object
purity is a tool to be used when appropriate, and discarded when appropriate. It is the outcome that is important, and for that there is no silver straightjacket that will force you to be successful. When I first started doing n-tier work I was a C++ developer.
A good one, if I do sayso myself. One who has written books on how to be "object oriented", who has studied, and taught it. I have also taught internal courses on Design Patterns and demonstrated them with examples from C++ apps I had written. In other words,
I KNOW how to "do objects". I've seen the OO debates and flame wars rage in the Visual C++ newsgroups--especially in and around MFC. And of course, the OO purists are right--MFC is NOT a perfect model for OO design. But there's a "funny" thing about MFC --
while the purists vent their ptolomics against the "object blasphemy" committed in some parts of MFC's design, or the inferiority of its "Document-view" architecture to a "pure" MVC implementation, hundreds of thousands of developers have been using it for
over 10 years now to create award-winning applications. Now I realize that a design such as I described will never be a candidate for your commercial product, nor for Object Spaces, or whatever they end up being called. And who knows, maybe the little test
project I'm playing with in what used to be my spare time will result in a major change in how I design things, but not this year. Meanwhile, we're well into our third moderately complex .NET app now (30 tables in the database, a dozen 'main' use cases, about
50 screens) using this approach, and the approach is holding up well. The two prior apps have proven easy to maintain, one of them through a major cycle of enhancements and modified features. The other one is scheduled for a similar cycle 2Q next year, and
from the requirements I've seen so far, it will handle it easily. The current one is coming together nicely and enters UAT next week, on schedule in spite of three major requirements changes halfway through implementation, and I am about half-way through design
on a fourth similar app that we expect to implement to begin production at start-of-business 2004. As to what layer should be talking to what layer, that's another design issue that, IMO, ends up being more a matter of semantics than anything else. I just
find it easier to speak in terms of a DAL that encompases all aspects of data access -- I ask it for some data and it returns it to me, and who cares how many internal layers it may have. Nothing that is "database specific" leaves the DAL. You may have a more
narrow concept for the term, or a broader one. Same for business layer. I just know that when my UI needs data for some display, or needs some user-requested operation carried out, it calls a single method in it's supporting bal component and it ends up with
what needs to be displayed, and when the user says "update", the ui passes the data and any special "user instructions" back to the bal's "Update" method and that is it. The BAL, in turn, knows "who to talk to" to acquire the data or to carry out the user's
instructions. Oh, and about the "Order and OrderItem" object approach. Been there, done that. Our experience was that it is a very nice, elegant design to work with, and definitely has its advantages, but the existing toolset at the time (this was pre-.NET,
COM+ style coding) was just not efficient to use. It took more coding up front to put it in place, and there were too many places to change when the data model changed, as it commonly does during development. To be sure, by the time you reached the UI, it
was beautiful to behold. But the work of maintaining the plumbing was more than a small team with mandated corporate deadlines could live with at the time. Perhaps if we were to re-visit the approach we would find things better in .NET, but there's an important
piece still missing that I think has to be there before that approach becomes viable -- , integrated modeling. I'm a huge believer in modeling. (no jokes about weight watchers, please). In one of my Grady Booch books I have a diskette with Rational Rose, version
0.9, and that hooked me on modeling tools. Problem is, I still haven't found one that really seems to offer any real advantages over an app's lifecycle. The piece that is always the kicker is round-tripping. Today's development cycle for the kind of stuff
we do just can't afford the kind of total up-front design that you need to take real advantage of modeling tools, because once you push the button and generate the skeleton app, and start writing code, kiss the modeling tool goodbye. Got a change that goes
across objects? Too bad. I tried using the little subset of Rose that MS provided at the time, but its roundtrip was inadequate to the task. I revisited the concept when I saw Rational's XDE, but it was not even as useable as some of ASP.NET's m1 bits, and
now that IBM owns Rational, I would expect WebSphere to be the favored environment. I have hopes for some stuff in Whidbey, but it isn't far enough along to tell yet. I do know that where I think the future lies is in a roundtrip modeling tool that is fully
integrated with the IDE. And at that time, things that are too burdensome to design, code and maintain today may be the way to go tomorrow. Oh, btw, I am well aware that you have a commercial object-mapping product. I am not trying to detract from it. Perhaps
it will succeed to the point where a large, very conservative company would not put my head on a pike and parade it up and down the halls for doing an important project with an "unapproved vendor" product. That's another thing we often have to live with--the
realities of the environment in which we operate. Anyway, I have digressed far beyond the original subject. I do not apologize for my design _choice_, nor do I accept your criticism. It is definitely not your approach. Fine. But your approach is NOT the only
acceptable one. Mine is not wrong, it is only different from yours. It has let our very small team, on which I am the only senior type, produce several apps that have been delivered ahead of time, that have met all expectations and have proven to be very maintainable.
And I bring the insight of a LOT of years experience with successful (and failed) applications, to support my views.
Hi All I have recently written a CRUD Generator that uses Microsoft.ApplicationBlocks.Data so if anyone is interested please let me know. The generated Classes and Stored procedures support ACID principles. The CRUD generator essentially encapsulates all my
working knowledge into one neat little package to save myself considerable development time. (WinForms app) I basically followed the KISS and 80/20 rules when writing this little app so it is by no means perfect. In my case the tool creates 70-90 percent of
the data access code I will ever need for a given database in a matter of seconds. The CRUD generator addresses the following issues: Transactions - updates, inserts and delete methods are overloaded to support optional passing of transaction objects. In that
way you could manually create a composite class that utilizes two or more CRUD generated classes and pass a transaction to all the participating objects. Either all the changes commit or everything is rolled back. Optimistic concurrency - All a DBA needs to
do is add CreatedDate (datetime) column to table and CRUD generator will create all the necessary logic to check for optimistic concurrency violation. Only stipulation is that the developer passes original Datetime value back to procedure so valid comparison
can be made. I leave cascading deletes and restricted deletes up to SQL server as it should be. In all delete stored procs the CRUD generator simply traps error 547 (foreign key violation) if user attempts to delete primary key that is referenced in another
table. I then throw a friendly error message using RAISEERROR. CRUD Generator Limitations: <-- I would not characterize these issues as limiatations but others may. ie C# developer - Every table must use a single column to represent tables primary key. The
column must utilize IDENTITY attribute and appear as first column in table. - Binary data types are currently not supported. - Only supports SQL Server - Only VB code is generated Some additional features of CRUD generator: - User can point to new database
by simply changing connection string in applications config file - User can select one or more tables they wish to generate classes or stored procedures for - User can specify namespace that all classes will utilize - User can specify which methods and stored
procedures are generated (i.e. insert, delete, update and so on) - User can specify if they want datareaders or datasets returned to client applications. - All the stored procedures are written to a single file for convenience - Each table has its own class
generated. The naming conventions is table name followed by DB suffix. For example, Employees table would have generated class called EmployeesDB. - For CRUD generated select procedures the user may optionally define additional columns that are included from
related tables - The CRUD generator will generate select procedures for all foreign keys found in a table. By foreign keys I mean columns with a suffix of ID. ID is simply the convention I use. For example, imagine Employees table had a field called ManagerID.
The CRUD generator would generate a stored procedure called EmployeesGetByManagerID that could be used to retrieve all the employees that fall under a given manager. I took a look at LLBGEN as well and I thought it generated a lot of unnecessary code. Regards,
Kevin Weir kevinweir382@hotmail.com
Jim, your posting makes m very sad, because it appears to me (and I may err here) that you have lost your bite, so to say. I could get this wrong, but it sounds to me like your choices are not based on knowledge that is relevant, but on knowledge that is outdated,
and I hope personally never to go this way. Let me sum up why: * You say basically you have tried the object model approach a long time ago. AND it was not viable. Let me quote: "but the existing toolset at the time (this was pre-.NET, COM+ style coding) was
just not efficient to use". Dit it ever appear to you that this has changed? I was using O/R mappers and object models about 6-8 years ago in Java. I was getting into VB for a project, an I looked around for the same, and all I could find was COM+ based and
garbage, or it was Lhothks's "Working with Business Objects in VB6" which was also a toy, functionality wise - NOT that I want to downplay him. Lhotka delivered a model, but it wa written in VB, and it showed. As you pointed out: the toolset was not right.
You can not work around the VB6 limitatiuons in VB6. BUT - .NET has changed this. It has opened a lot of new possibilities, and I must say: I love them. MS has manufactured in some limitations compared to java, but also put in a lot of good things. An O/R
mapper like the EntityBroker would be possible in Java (in fact, one of the reasons our customers propably like it so much is that I have modelled it afte rsome products around for years now in the java world), it is possible in .NET. It is definitly NOT possible
in VB, and I think it would not be possible to make in C++ either (RTTI limitations, mostly - maybe you could work around some with templates and a lot more generated code). The ruleset and toolset has changed. YOu should have a now look on the facts - the
way you state it, your facts are a little outdated. BTW - I pretty often put exactly this comment over to java developers, too. .NET has some remarkable features that expecially java developers have a tendency to miss out, as the systems are so similar on
first look. ::Perhaps if we were to re-visit the approach we would find things better in .NET, but there's ::an important piece still missing that I think has to be there before that approach becomes ::viable -- , integrated modeling. I fully agree. We are
trying on this way right now, with an editor, and we play around with getting something like an UML class view into it. THe problem with external modelling tools is their missing information (how do I define additional metadata there that the persistence layer
needs?) ::And worse, they are trying to apply concepts that were conceived of in the days of rich- ::desktop client-server apps to the world of n-tier, browser-based web applications where ::today's client is a web browser, but tomorrow's may be a distant
server talking to us ::through a web service or a hand-held cell phone. I think you have an error here. Basically, I always define my busienss layer so that I CAN attach a rich client object OR an ASP.NET application. The business layer should be agnostic
to this. Besides, I wish people woud write less ASP.NET applications at times. A winforms app has some merits. We work on an online shopping system at the moment, and - we decided to go with a regular app for maintenance. It is SO much more convenient than
going the ASP.NET route. ::In one of my Grady Booch books I have a diskette with Rational Rose, version 0.9, and ::that hooked me on modeling tools. I wont comment on this. Well, I will: Rational Rode is propably a sample of an overmodelled tool. Their early
versions are not really good, not usable and buggy. Today, their outstanding feature is their price :-) ::Meanwhile, we're well into our third moderately complex .NET app now (30 tables in the ::database, a dozen 'main' use cases, about 50 screens) I would
not call this moderatly complex :-) I call this simple. I think our upcoming online shop catalogue (ONLY the catalogue) has already more than 30 tables (whoever does not believve it - read the Data Model Ressource Book and look on what a shop CAN be - I mean,
their address management has about 30 tables).
I enjoy you guys discussion or debate. I came from UNIX-VB-ASP, and was not quite object oriented. At the .NET age, I have chance to be more OO. But, remember, in the real world of application developments, OOP only occupies a small share (<<50%). Most applications
are Data-centric RAD, business oriented, tool oriented or solution oriented. I enjoy using DAAB. See more discussion about DAAB and LLBLGen at thread
279698. I like the idea from JimRoss that combining DAAB and LLBLgen and using LLBLgen to create some needed source code, for example, SP.
MCAD.NET (C#)
MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0
JOAC
Participant
1880 Points
376 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 23, 2003 06:03 AM|LINK
JimRoss [MVP...
Star
10080 Points
2008 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 23, 2003 10:11 PM|LINK
MS MVP ASP.NET [VC++/MFC emeritus]
Old Dog Learns New Tricks
Preferred programming language: cuneiform on clay tablets
JimRoss [MVP...
Star
10080 Points
2008 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 24, 2003 12:13 AM|LINK
MS MVP ASP.NET [VC++/MFC emeritus]
Old Dog Learns New Tricks
Preferred programming language: cuneiform on clay tablets
kevin.weir
Participant
850 Points
170 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 24, 2003 04:31 AM|LINK
thona
Member
20 Points
2923 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 24, 2003 07:02 AM|LINK
ghan
Participant
1440 Points
288 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Sep 06, 2003 03:24 AM|LINK
MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0