I appreciate the advice m7 - but I think the point SteveFlit is making is that different web solve different needs and have different requirements. Your architecture seems to me to work fine for small apps with a finite set of complexity, but what about a performance
critical web app that needs to be as efficient as possible? In this situation using metadata to determine what data to query is simply not efficient if we want to deal with things like XML, and more advanced queries and data refinement. Its good to get different
perspectives, but theres no "better" solution, otherwise Microsfot would have added wizard for it!!!
it certainly does work great for large scale apps. i have in-built caching of objects for one thing (configurable per object). so it means i dont have to go to the database each time. remember, your metadata is also cached, so are your queries. everything.
also, the larger the app, the more time is saved in terms of development. the saved (expensive) development time, can buy a *lot* in terms of memory and processors. upgrading your hardware is far cheaper than developing a custom persistence layer each time.
give me an example of one query that you couldn't handle with a generic persistence layer. and in what way do you mean "deal with things like xml"? if that was a requirement, you could build it into your persistence layer. make everything generic. > but theres
no "better" solution, otherwise Microsfot would have added wizard for it!!! this is a better solution, and if you need microsoft's version of it for proof, microsoft *is* coming out with an object broker like i have described in 2004 named ObjectSpaces.
Um, you have to write those business entities anyway, either in the business entity or business object. In his architecture, he just writes them in the business entity and not the object. In yours, you write it in the business object. Furthermore, "my" data
layer does NOT need to know the specifics of your business entity to pass it. That is what factories and inheritance are for. "my" dal does not need to be recompiled when a new table or mapping or whatever exists. On the other hand, you seem to be proposing
one of the following, and you tell me which it is: a) always pass object arrays at all layers b) use object arrays from DAL to business layer but use business objects elsewhere Furthermore, he did not ask about or mappers. He asked a specific question and
your answer instead criticized his approach, despite it being a core recommendation for reduced network traffic. Lastly, there are cases where, believe it or not, or-mappers are simply not viable. However, transfer objects or similar may still be desired.
If he's hosting his data layer on a different server, certainly passing something easily serializable that does not involve round tripping is necessary.
OK, Again, I dont have much in the way of .NET hands on experience, so heres an example from my old COM days: I need to get a list of people that have done a course, the version of the course they did, and also the current latest version of the course. This
query is fairly complex in that it needs to make use of a SELECT...GROUP BY...HAVING query. How would you handle this? We would have to create a method in the Data layer called "ListUsersAndCourses" or something similar. This retrieval of data is something
that I struggle to improve in terms of reduced code. Would you need to implement the same solution as this, or does your architecture provide an easier way? Having throught a bit more about what you said, am I right in assuming that your metadata system only
handles UPDATE, ADD, and GET operations? Thats V. interesting about ObjectSpaces, I'll have to chekc it out...
Hi Matt, "This retrieval of data is something that I struggle to improve in terms of reduced code. Would you need to implement the same solution as this, or does your architecture provide an easier way?" "Your architecture seems to me to work fine for small
apps with a finite set of complexity, but what about a performance critical web app that needs to be as efficient as possible?" First one needs to decide what are the benefits one wants to collect from such effort. Probably a balance between both statements
between both. "but what about a performance critical web app" A Performance critical web app going to the database to process every single request, more over with queries that are complex? Humm, in the end probably you'll need some caching architecture to
avoid such requests to the database. "Yep, thats exactly what the code is doing - the business entitties are simply representations of the underlying data, as Steve says they are structs.From a coding viewpoint its very useful to work with these business entities,
and we can automate much of the entity poulate via reflection as Steve said" Humm, can you provide me with an example where this is really so much better then say working directlty with DataReaders and/or DataSets, that is direct ADO.NET based implementation?
Please, can point out the benefits in terms of architecture, reusability and performance? Thanks. Nuno
> In yours, you write it in the business object i dont write any crud. he has to. are u suggesting his crud magically appears when he creates a new entity? he doesnt have to write any sql?? > Furthermore, "my" data layer does NOT need to know the specifics
of your business entity > to pass it. That is what factories and inheritance are for. "my" dal does not need to be > recompiled when a new table or mapping or whatever exists. so how do you handle crud for a new entity? >you seem to be proposing one of the
following, and you tell me which it is i am proposing to create (or buy) a persistence architecture. then the problems of what to pass goes away. your business entities *are* your business layer. you dont need extra classes which handle the logic of your entities.
you encapsulate everything within the entity. persistence is handled by your persistence layer. crud functionality is not business logic. inside your persistence layer, between the object broker and the dal, you should be passing object arrays (or something
as equally fast, which will remote). you ask your persistence layer for an instance of an object. how you do this (passing it in as a reference, having it returned and cast it, whatever), is up to the user of the persistence layer. you could pass in a unique
identity and a type, and have an object returned. you could pass in a reference to an object with it's identity set and the rest of the fields will be set by the persistence layer. it should be up to the user. >Furthermore, he did not ask about or mappers.
He asked a specific question and your > answer instead criticized his approach he did not ask about or mappers because he did not know about them. he was asking how to auto-create business entities. he even asked if there were tools to do this. i explained
that or mapping takes away a lot of the problems he will have. his specific question was asked without full knowledge of the possibilities, and i'm well within my rights to suggest alternatives. if all we can do is answer specific questions, answer this one:
"i use a red shoe to drive in a nail. what color shoe do you use to drive in nails?". > believe it or not, or-mappers are simply not viable i agree... in reporting. in an oo environment with a relational database (which i believe is his environment), tell
me how they're not viable.
> I need to get a list of people that have done a course, the version of the course they did, ? > and also the current latest version of the course. This query is fairly complex in that it > needs to make use of a SELECT...GROUP BY...HAVING query. How would
you handle this? one of two ways - either by reporting, or by object query. your persistence layer should have an object query built in, so you should be able to do something like this:
Query q = new Query(typeof(User), new GroupByCriteria(...), new HavingCriteria(...); // or whatever
however, i would suggest the query you're trying to do is *not*
an object based query. it's more a list for reporting, and would question the use of business entities in this scenario at all, especially if performance is a key requirement. id probably just do the same as i would in a reporting environment and return the
data rather than objects.
Between the broker and DAL, yes. Between any other layers, no. Even between the dal and broker I feel it's a little riskier than other techniques. If somehow the wrong set of data gets passed in, it seems a little more unpredictable. How will you know what
that object array represents? What guarantees do you have that it's the right thing? With respect to OR Mappers, There are other situations, mostly involving existing systems. For *new* systems it's not as common. But if you have to build upon existing tables,
often times OR Mappers will simply not work as intended (that is, in terms of code reduction, etc.). They'll still work as a whole, but it is likely you'll have to do some manual work to get data into objects, because the Mapper will not be able to figure
out a non-trivial, efficient way to get the data. My comment was more to do with the seeming evangelistic tone of the posts. ORM may not be his situation... we don't know since he hasn't given a lot of details.
> Between the broker and DAL, yes. Between any other layers, no but what other layers are there (in my solution)? given that you're asking the broker for an object (so are passing in an identity), you're making no other layered calls. your front-end asks the
broker for an object every time. as far as being riskier and what if the wrong data is passed in - that's up you (or whomever writes the persistence layer) to ensure it's bug-free. a user can't pass the wrong data in - because it's the broker that's passing
the data in. as long as the broker is coded correctly (which we have to assume - we have to assume sql server is coded correctly right?), we will get the expected results. id still be interested to know of a specific instance where you couldn't have let an
o/r mapper at least handle the crud for you and save you having to write that, in any database schema, even an existing system. apologies if the tone came across as evangelistic.. not my intentions at all. i was just surprised to be shot down by suggesting
not passing in specific entities and instead making your dal as generic as possible.
MattWoberts
Member
361 Points
80 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 03:16 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 03:26 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 03:34 PM|LINK
MattWoberts
Member
361 Points
80 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 03:40 PM|LINK
billym2000
Member
10 Points
2 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 03:43 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 04:15 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 04:30 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 04:38 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 04:41 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 10, 2003 04:50 PM|LINK