Andres Aguiar's Weblog

I just read it Andres and you're right, it's definitely an eye opener.

Sorry Andres, but I find the article of exceptional low quality. First I really find it simply a sign of "I don't know what I'm talking about" when an author talks about 'CRUD' in a context other than lowlevel database operations. CRUD is a term used for typical queries on tables, not something else.

Then the author shows absolutely no writing skills whatsoever. It's clear he knows the difference between an entity and a business component, but he fails to name the two as different types of objects meant for different layers in the application. Because of that failure, the article is unusable. Had he explained that there is a difference between a business component and an entity, (i.e.: a business component typically aggregates / is based on one or more entities) it would have been at least readable and understandable. Furthermore he would have had a way to position business logic, the real reason he doesn't seem to like 'CRUD' or whatever he thinks it means.

As a last point he actually totally ignores business logic positioning and the different categories of business logic:
1) low level, field oriented business rules, like orderquantity >=0
2) low level multi-field, single entity orienteed business rules, like order date <= shipping date
3) multi-entity business rules.

Because he thinks there is only category 3, and 3) is also only implemented as a service and because of THAT it is hard to go forward with 'crud' operations on entities (which should be business components).

About YOUR posting, Andres: "If you think you can have the same methods in your business logic layer, read it.". Well, a gui updates a set of order detail rows. How to tell the system to update these in the persistent storage? Ok, by sending the updated entity / business component down the tier stack. BUt the article writer didn't say so because he completely ignores the fact there is even a concept like a 'business component', the cornerstone of MS' MBF even!

People who DON'T use tools like mine or yours, what choice do these poor sods have? :) Datasets, it's the only (!) way MS wants you to deal with data. What message does MS now send to these developers? Don't use datasets? Don't use n-tier development with a BL component which exposes methods so I don't have tight coupling between a database table and the gui? (remember, that was MS' rethoric of the late 90'ies!)

No, all I can say is: the article is very poorly written and will mostly confuse developers instead of helping them: poorly usage of industry standard terms and no clear discussion about how to do it right.

Hi Frans,

I really don't want to argue if the article is well written. I agree it requires to read between lines.

I think he does understand the difference between an entity and a Business Component, and his main point is that a service layer should work with Business Components instead of entities. I think the same thing goes if you are building a business logic layer that needs to be used from different tiers.

BTW, even if he seems to say that you should not use DataSets, he's not saying that ;). He's saying that you should not persist the DataSet directly to the database (i.e., using a SqlDataAdapter). You can use a DataSet, perform the kind of checks he says regarding concurrency, apply business logic that ensures that the whole data set is valid, and then save it.

>People who DON'T use tools like mine or yours, what choice do these poor sods have? :)

For data access, people who is building simple apps don't care. I want to think that people building complex apps use a commercial tool or a homegrown tool that tries to solve similar issues.

Now, this article is not about data access, and there aren't a lot of tools that help you to build what he's suggesting.

I'm with Frans on this one. In fact, whenever you make some universal declaration that you should or shouldn't use something like this, someone will come up with dozens of reasons that show why you're wrong.

Denouncing CRUD is CRAP. :)

Jeff,

So, you are universally against all universal declarations? ;)

He's talking about CRUD at the service level. And he says you can use it sometimes so is not an universal declaration.

Regards,

Andres.