Hi
I think my question might be answered already in this forum(but i didnt find any post) as it was the first thing wich struck me when i used CSLA.NET. Ill be glad if some1 thrws light on this:
Wat confuses me is that CSLA.NET uses data access code in the business layer only. wat abt those age old rules of making BL independt of DAL? if one has to change the data store, then he needs to modify BL. am i corrct here?
let me knw yr thgts
Vivek
I've seen threads discussing this topic on the forum.
(Sorry, don't have them handy, you'll just have to look again unless someone else posts where they are. :)
The threads discussed how you would go about changing the class structure to allow for a totally separated DAL.
IMHO, unless you have a business need to support multiple DALs at the same time, it's not worth the bother. It just means you have two files to keep in synch instead of one. The DAL components within the CSLA business objects are logically separated from the other methods even though they are in the same class, so it's not like the DAL and business rules are all jumbled together in a haphazard manner.
If you do have to support multiple DALs at the same time, it obviously would be worth the bother!
thanks david!
i agree with you. Also i noticed one more thing: In the sample projects tracker app, we have DataTransfer Objects (DTO) being used to pass data instead of business logic across layers. I know the pros and cons of such approach, and have a query:
in my project i am using a business layer, a web service layer and a DAL. now i have creatd DTOs for each object and have put them in a Common Lib project. the BL communicates to DAL using these DTOs. now the WebService also uses DTOs to talk with BL. And the WebService passes these DTOs to the GUI. Since i am using DTOs throughout, i dont need to map Buisness Objects to DTO (no use of DataMapper.cs). Is this approach fine? Or do u find any potential flaws in this?
vicky_iit:
in my project i am using a business layer, a web service layer and a DAL. now i have creatd DTOs for each object and have put them in a Common Lib project. the BL communicates to DAL using these DTOs. now the WebService also uses DTOs to talk with BL. And the WebService passes these DTOs to the GUI. Since i am using DTOs throughout, i dont need to map Buisness Objects to DTO (no use of DataMapper.cs). Is this approach fine? Or do u find any potential flaws in this?
This is fine, as long as you realize that you have TWO applications. Web Services should not (normally) be used to communicate between tiers of an application, but rather should be used to communicate between separate applications. The whole point of using web services and DTOs in a message-based architecture like this is to decouple the two applications so they can version separately.
Now I realize that precious few people do this, choosing instead to misuse web services as a (rather lame) client/server network protocol. And if that works for you great! But the direction the web service and SOA industry support is moving is not to support client/server models and you should expect your life to get harder and harder as time goes on, and vendors like Microsoft move further and further from allowing their SOA technologies (like web services or WCF) to provide support for what we think of as client/server.
Another caution I'll toss out here is this: your DTO in a web service is part of your external contract. Thus, I strongly believe you should not use it within your actual business layer. The reason is that decoupling goal again - you want to be able to alter your business layer, or the consuming application, independently. If you've tighly coupled your internal implementation to the external contract (the DTO) then you can't get this type of decoupling and all the benefits of web services are out the window - leaving only the high cost (inefficient XML serialization, etc.)
In my view, as I explain in Chapter 11, a web service is just another type of UI on top of your business objects. The "user" in this case is another application, but the archtiectural reality remains the same: the web service is just an XML UI and should be treated as such.
From the consumer's perspective, a web service is very much like a stored procedure. It is a remote procedure that you call, passing in some parameters, and getting a set of data as a result. Architecturally web services should be treated no differently than a database when writing a consuming application - with the one exception being that you must assume that the web service is used by other applications as well, and so you can't trust it like you might trust a database that only your application uses.
I've blogged about this sort of thing quite a bit - mostly about a year ago - so you can find a lot more thoughts by looking back through my blog history.
Hi Rocky!
thanks for giving a detailed and informative reply. regaridng my app, Web service is not a layer above BL but a separate project independent of the app.
If i get u correctly the scnario should be: since BL and DAL are seprate projects, the BL sends DTOs to DAL which fill them up or uses them as needed and returns back to the BL. the BL can then use this DTO to set its object properties and the return that object or its collection to the service interface. now if i dont do this, what is the other option i have? i think BL is not tightly coupled with the DTO layer as BL only references DTO one way only. DTO is unware of the BL. i dont want the DAL code in the BL classes as my project needs to be DB independent.
let me knw yr thgts on this
thanks
vivek
thanks Rocky!
yr answer clarified everything nicely! i wish u cud give seminars in India too!
thanks
Vivek
I believe you can avoid the problems mentioned about the DAL by using explicit interfaces and flags. You would create an explicit interface that would include the properties for each class and place them in a separate assembly. Each class would implement their own interface. The same properties that are used by the presentation layer would be used by the DAL to load the object. The explicit interface allows you to load the private properties while hiding them from the presentation layer. The only way to access these private properties (not including reflection) is through casting to the interface. However, since the interface resides in another assembly, the presentation layer would never have access to these private properties. Each interface would also include a LoadingFromDAL flag. This flag would be set when the DAL is loading the object. You can use this flag in each property to avoid checking the rules etc.
hey malloc!
thanks for yr reply..ill look into this approach!
vivek
really nice post....
Hmmm... interesting. These concepts have been on my mind recently and I'm glad Rocky gave his insights here.
My thought process has been like this:
I like the idea of a DAL-DTO regardless of any web service discussion. The idea of using XML for this has been interesting because of the inherent flexibility. For example, it seems like it would be valuable to have a little bit of looseness in the coupling between BO and DAL such that an extra column showing up in the DTO doesn't break anything... similar to the way there are modifications you could do to a table, view or sproc without breaking "classic" CSLA data access.
Once you go down the path of saying that the data acess of a BO is only that it knows how to persist and save itself via XML, with that flexibility of dealing with extra (or missing?) columns, then you're 90% of the way to enabling web service access to the BO.
I still think the general concept is valid in that there's a lot of code reuse possible if you think about a BO having that general capability, but there is still indeed likely a difference in the contracts on the web service side vs. the DAL side.
Or am I completely out of my mind in thinking that I'd like my BO to be able to continue working with somebody submitting an "old" XML schema version or only just a few fields via a web service? From my experiences working with one of our web service enabled vendors I can say it's quite nice to be able to submit just <customer ID="123291" LastName="Smith" /> to change the last name even though there are 100 other fields in the full customer BO.
Once you go down the path of saying that the data acess of a BO is only that it knows how to persist and save itself via XML, with that flexibility of dealing with extra (or missing?) columns, then you're 90% of the way to enabling web service access to the BO.
I am not sure I agree with this. I view object persistence as fundamentally different from UI interaction. The DAL is persistence, a web service is UI and the object is in the middle. The parameters for dealing with your UI are quite different from a typical DAL interaction. You don't trust the UI (or at least the user), but you do trust the DAL in many cases. In other words, you run validation and other business logic against anything coming from the UI, but you rarely run all that logic against data coming from the DAL.
Conversely, you'll give data to the DAL that you'd never give to the UI - sensitive values, values that aren't formatted in certain ways, etc. You might give the UI someone's age, but you'll give the DAL their birthdate. Stuff like that.
So I agree that the mechanics of dealing with XML are possibly common, I'd suggest that the way in which the interaction is treated is fundamentally different.
That, and the object should never generate the XML for a web service. That's blurring the line between UI and business layers, and is exactly the same as suggesting that your object should generate the HTML for a web page, the XAML for WPF and the Windows Forms controls for WinForms.
Or am I completely out of my mind in thinking that I'd like my BO to be able to continue working with somebody submitting an "old" XML schema version or only just a few fields via a web service? From my experiences working with one of our web service enabled vendors I can say it's quite nice to be able to submit just <customer ID="123291" LastName="Smith" /> to change the last name even though there are 100 other fields in the full customer BO.
Not at all. But this is the job of the web service UI, not your business object. It is absolutely a goal of web services (service-orientation anyway) that you should allow the service consumer and provider to version independently. And that, by definition, means that you must accommodate old versions of your XML messages.
As soon as you stop honoring an old version, you break any consumers using that version and force them to update their code - and at that point you've re-coupled the consumer and service. Obviously in real life this will happen, which is why SO isn't a silver bullet. However, it is certainly the case that you can honor a number of old contracts over time, and so SO does have great value in this regard.
But to return to my point: this handling of old XML contracts isn't the job of the business layer. The job of the business layer is to implement the business use case. If you want to support old XML contracts, that is the job of the XML UI. It is then the UI's job to "fill in the blanks" for missing data, etc.
Rocky
Rocky,
Yr recent posts forced me to ask you one more query, slightly more granular. sometime back i was wrking on a project whose BL layer used to talk with DAL using DAL DTOs.
There I noticed that the BL objects never had any private members but used the DTO itself.
Eg.: there is a Customer class with 3 attributes.
now, when thinking of using DTOs, my approach is like:
class Customer
{ private string _name;
private int _age;
private int _id;
public Customer() {} //public constructor
internal Customer(customerDTO data)
{
_name = data.Name;
_age = data.Age;
_id = data.Id;
}
public string Name
{
//return this._name;
}
//similary properties for each private attribute that needs to be exposed.
}
Now, in CustomerList class i will have some method FindCustomers(criteria) which will return a list of CustomerDTOs. I will then instantiate a new Customer object passing that DTO in the constructor.
But in that project, I noticed different behaviour. The DTO was passed in the Customer objects constructor but the code was like:
class Customer
{
private CustomerDTO _data; //no other private attributes
internal Customer(CustomerDTo data)
{
this._data = data;
}
public string Name
{
return _data.Name;
}
//similarly other properties
}
Now, i think that this approach isnt right as BL is now more tightly coupled with the
DAL DTOs. Its like intead of the BL defining the attributes, the job is upto the DTO. Am i right?
wud luv to hear u on this.
vivek
Hi,
first of all, I'm new to this forum and new to CSLA, so excuse me if I ask stuff that has already been answered.
I followed the whole thread and it gave some insight into the way people do Data Access.
But I found this thread while I was looking for something slightly different. I am looking for a way to separate the BO from the Data Access calls but only for one specific reason:
We highly rely on SQL Server and stored procedures. And we are in the process of migrating to vb.net (and the new SQL Server 2005). While prototyping (and before we found CSLA, which we really want to use as base framework) we did some data access stuff where we use stored procedures that expect only one parameter, an XML document and return an xml document. We simply serialized the business object to XML and sent it to the stored proc where our DBA wrote code to "flatten" it and do some key checking (the primary validation was done in the business object), then the data is saved to the related tables and the saved object is returned again as xml string. This allowed us to simply deserialize the xml to a fully functional business object without setting every property one by one. And it provided us with a simple way to execute our stored procs without providing numerous parameters.
We liked this approach and I am trying to implement this same behaviour with CSLA. The problem now is of course that the DataPortal_XYZ functions are instance methods and I cannot deserialize the returned xml document into my current instance.
So, after a long and boring intro my question is: is it possible to redirect the DataPortal calls to another class that instanciates my BO and returns it to the CSLA object or is sending and retrieving xml to a stored proc simply a bad idea. (What we don't want to do is giving the business developer direct access to the underlying data tables of the data base)
Please let me know your thoughts or if there's a possibility to use external data access methods
Kind regards
Mike Dobler
Thanks for that input, Lakusha. If this can really be a problem we must look into that and do some good testing.
Regards
Mike
Hi again,
even if I'm told that relying on XML transfer in and out of an SQL Server 2005 might result in a badly scaleable database we still think that sending back and forth the whole data structure as xml has some nice things about it too. For one thing, you're completely transactional within you parent/child data when sending it as a complete package to the server and the other thing is the nicely instantiation of complete classes, which would erase the need for some dull data reading code.
What I've found in this forum to circumvent the problem of instantiating a complete CSLA class is the use of DTOs (data transfer objects). I did some testing where I wrote a DTO whose XML-Element attributes match those of my SQL Server returned document and whose Public Fields match the private fields of the corresponding CSLA class. Then I can use the DataMapper from CSLA to quickly copy the info to and from the CSLA class to the DTO class and then serialize the DTO class and send it to the stored procedure. And by matching the Public fields of the DTO to the private fields of the CSLA class I won't trigger any validation code.
My question now would be: Is the additional code worth the resulting easiness of programming or does the data mapping and serializing result in a huge loss of performance? And does anybody have practical experience in using XML on SQL Server 2005 (which should be lots better if you trust MS)
Regards
Mike
Hi Brian,
thanks for your reply. I know that CSLA does support transactions and it does make sense to control transactions in the client code (meaning everything but SQL Server in this case) if you are accessing multiple sources but in our case we are using only one (large) database and loading all the validation and lookup data (for foreign key checkings, basic data integrity and so on) into the client code didn't seem very appropriate to us so we encapsulated the basic lookups and reference checkings into stored procedures - so it made sense to us to try to load and save complete structures instead of single data rows. And our DBA wouldn't let us write directly into the tables anyway;-)
...My thought process has been like this:
I like the idea of a DAL-DTO regardless of any web service discussion. The idea of using XML for this has been interesting because of the inherent flexibility. For example, it seems like it would be valuable to have a little bit of looseness in the coupling between BO and DAL such that an extra column showing up in the DTO doesn't break anything... similar to the way there are modifications you could do to a table, view or sproc without breaking "classic" CSLA data access.
Rocky gave some excellent reasons not to do it.
Personally, I would rarely choose xml as a data access method for business objects (whose code I control) for day-to-day access to a database (whose code I control). It's going to shove gobs more data over the network than a result set would - not only the data has to move, but multiple copies of each XML tag! Not only that, but if the data set is large, you can spike the memory usage on the machine that has to process the xml file.
XML isn't the end-all and be-all of data transfer. It's a nice technique that's been grossly over-hyped - like pretty much anything else in our line of work that marketing folks realize can pry money out of technically incompetent managers. :)
XML is great for somewhat self-documenting small configuration files, and handy for ad-hoc transfers of data across disparate technology stacks.
For reliable, day-to-day electronic data interchange (EDI) operations, it suffers from the same problems that EDI operations had in pre-XML days. People:
EDI systems came with data validation tools that people failed to use correctly and XML comes with schema validation tools that people fail to use correctly. And, regardless of what the standard's body says, the one with the big bucks in their wallet that the other party wants wins the argument as to what will be put in the file.
Copyright (c) Marimer LLC