Business Objects
-
Jon Rista wrote:
I would remove .Save() from all of your business objects entirely, and isolate all persistance logic completely within your DAL. You have the fundamental issue that I call "Blending of Concerns" (I guess it could be called an anti-pattern).
Sounds like the Active Record pattern. (Although I'd have to see the code to be sure, but it sounds like it could be).
* Developer Day Scotland 2 - Free community conference * The Blog of Colin Angus Mackay
Vogon Building and Loan advise that your planet is at risk if you do not keep up repayments on any mortgage secured upon it. Please remember that the force of gravity can go up as well as down.
Yeah, CSLA from the book 'C# Business Objects' basically an Active Record implementation. Lhotka blends a lot more concerns than persistance into his business objects, however...its like a monstrous glob of blended functionality...quite frightening when its actually put into practice. ;)
-
Well, it may not be the answer your looking for....but I would remove .Save() from all of your business objects entirely, and isolate all persistance logic completely within your DAL. You have the fundamental issue that I call "Blending of Concerns" (I guess it could be called an anti-pattern). You have mixed the concerns of persistance with the concerns of your business, which, while it can make the USE of your object model simple...it greatly complicates maintenance and extension. If you are really looking for the "best" way, I would say that one of the best ways is to follow Domain Driven Design (DDD) and implement a Domain Model. Domain models are systems of business objects (entities and value objects) and some support types. Entities implement business rules, but contain absolutely no persistance logic (or, perhapse some minimal support for persistance through the use of specialized collections). Repositories encapsulate the bulk of persistance logic. Instead of calling stored procs, an Object/Relational Mapper is often used to automatically handle graph retrievals and inserts/updates/deletes of graphs of objects. You will end up with more objects by following DDD principals, but each class will be responsible for less, do less, and generally be smaller in size. Services wrap up the orchestration of loading, editing, and saving business objects with the repositories, a unit of work, and any other support types. http://domaindrivendesign.org/
Jon Rista wrote:
If you are really looking for the "best" way, I would say that one of the best ways is to follow Domain Driven Design (DDD) and implement a Domain Model.
+1 I agree completly. The main problem I have seen with active record pattern is the difficulty to write tests. BTW, Good post :)
Navaneeth How to use google | Ask smart questions
-
Jon Rista wrote:
If you are really looking for the "best" way, I would say that one of the best ways is to follow Domain Driven Design (DDD) and implement a Domain Model.
+1 I agree completly. The main problem I have seen with active record pattern is the difficulty to write tests. BTW, Good post :)
Navaneeth How to use google | Ask smart questions
Agreed...AR is a pain to test. I know that its one of the patterns Fowler describes in some of his books, but its really a blending of concerns that just muddies the business layer and makes maintenance and extension of a system difficult. It also breaks the cardinal rule of single responsibility. ;)
-
Agreed...AR is a pain to test. I know that its one of the patterns Fowler describes in some of his books, but its really a blending of concerns that just muddies the business layer and makes maintenance and extension of a system difficult. It also breaks the cardinal rule of single responsibility. ;)
What readings or books do you recommend for DDD? Is it a tough concept, how long before one can put it into practice--I know this varies from individual to individual but for someone who has extensive knowledge of OOP&D.
-
What readings or books do you recommend for DDD? Is it a tough concept, how long before one can put it into practice--I know this varies from individual to individual but for someone who has extensive knowledge of OOP&D.
The only book to really recommand is THE book on DDD. ;) Its called "Domain Driven Design: Tackling Complexity in the Heart of Software", by Eric Evans. Its an awesome book, first on my list of recomendations for aspiring architects and curious programmers. http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 The concept is really not that hard...the general idea is that software is intended to directly model business processes and meet business needs. Evans introduces the concept of using a conceptual model of the business and its entities as the central piece of a software project, and which is in turn used to create the 'domain'. The domain is a direct implementation of the concepts in the model, and contains some other facilities such as factories and repositories to support technical needs. A lot of the individual concepts and patterns are familiar...its the whole thing together that really makes a true difference. Some of the key things Evans advocates are full isolation of the domain from persistance logic, which gives it fludity making it more adaptable to the constant requirements changes that occurr on a daily basis (something most programmers have come to hate). The intriguing thing about DDD is that it takes that factor of constantly changing requirements and just factors it into the design and development process in a way that actually works...in (significant) part because of the strict separation of concerns between domain and persistance logic.
-
The only book to really recommand is THE book on DDD. ;) Its called "Domain Driven Design: Tackling Complexity in the Heart of Software", by Eric Evans. Its an awesome book, first on my list of recomendations for aspiring architects and curious programmers. http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 The concept is really not that hard...the general idea is that software is intended to directly model business processes and meet business needs. Evans introduces the concept of using a conceptual model of the business and its entities as the central piece of a software project, and which is in turn used to create the 'domain'. The domain is a direct implementation of the concepts in the model, and contains some other facilities such as factories and repositories to support technical needs. A lot of the individual concepts and patterns are familiar...its the whole thing together that really makes a true difference. Some of the key things Evans advocates are full isolation of the domain from persistance logic, which gives it fludity making it more adaptable to the constant requirements changes that occurr on a daily basis (something most programmers have come to hate). The intriguing thing about DDD is that it takes that factor of constantly changing requirements and just factors it into the design and development process in a way that actually works...in (significant) part because of the strict separation of concerns between domain and persistance logic.
Great I will check the book out. One question though: Rockford Lhotka's approach also separates the domain from the persistence logic, no? Do you mean tracking states of the object Dirty, Deleted, New and Save(), Delete() should not be within the domain and be placed in persistence logic?
-
Great I will check the book out. One question though: Rockford Lhotka's approach also separates the domain from the persistence logic, no? Do you mean tracking states of the object Dirty, Deleted, New and Save(), Delete() should not be within the domain and be placed in persistence logic?
Yes, I mean all of the persistance related stuff, his undo/redo stuff, etc. on his objects, which includes Dirty, Deleted, New, Save(), Delete(). Those are what we call "persistance concerns"...they represent a certain set of functionality and state that has nothing to do with the business, and everything to do with managing updates of data in a database. That blends the concerns of your business classes, which violates the principals of Single Responsibility (SR) and Separation of Concerns (SoC). These two principals are critical to creating maintainable software...software that has cohesive, properly-coupled components without reducing the isolation of specific kinds of functionality. CSLA creates an object model that is really convenient to use as a developer...having implemented it myself once, I liked the ability to save a business object just by calling .Save(). But I learned some really hard lessons on that project, especially the lesson about SR and SoC. Despite having used CodeSmith heavily on that project, the maintainability of such a coupled and blended architecture is atrocious. Even if you just have a .Save() method on a business entity that calls out to DAL classes that actually implement the operation...that business entity (and quite probably a specialized entity-specific collection class) are still tightly coupled to the DAL, and when the DAL changes, so do all the objects that rely on it. The problem is only compounded by cross-sampling behavior between related entities...such as having Customer also save its Orders when you call its .Save() method...take that a few degrees farther and you can probably see the nitemare for yourself. By following DDD patterns and principals, you keep the vast bulk of your classes loosly coupled, and aggregate the bulk of "orchestration" logic...logic that blends all those various concerns together to implement a process...into services. Such an architecture is much easier to change, as there is one, and only one, location to go to in response to changes in your DAL, entities, or support types (i.e. factories). Single Responsibility[^] Separation of Concerns[^]
-
Great I will check the book out. One question though: Rockford Lhotka's approach also separates the domain from the persistence logic, no? Do you mean tracking states of the object Dirty, Deleted, New and Save(), Delete() should not be within the domain and be placed in persistence logic?
Found this[^] - you have to register (painless and free) but then you can download it. Might be worth a look?
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia) -
Found this[^] - you have to register (painless and free) but then you can download it. Might be worth a look?
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)Thanks but I already went and got the book. Lets see what it provides and hopefully will be what Jon stated.
-
Lets say I have a few business objects such as Customer, CustomerCollection, Order, OrderCollection, Product and ProductCollection. The Customer object will have an OrderCollection object and Order object will have ProductCollection. The Customer will know all its orders because it has an OrderCollection, now Should each OrderCollection or Order also have a reference to Customer so they know who they belong to? For example, when you call Save() on Order object, the Order object will pass itself to DAL and DAL will need the CustomerID the Order belongs to so it can insert it into the database. Should the Save() method of Customer only save the Customer or should it also save the orders for the customer along with the products for the customer? Should the Load() method of CustomerCollection load all customers from the database or should it load the customers, their orders and the products which belong to the order? Should the Load() method of CustomerCollection only get the ids of all the customers and then pass the id to Customer.Load(string id) so the customer can load itself from the database or should the CustomerCollection.Load() get all the customer records and create Customer object by calling its overloaded constructor or perhaps calling Customer.Load(f1, f2, f3, ...) and passing all the fields? I assume there is no correct way and probably it is a matter of opinion but I just want to know which way is the best way. How do you guys do it and please do not suggest using ORM?
Hi there, I may as well chuck something in here, as I love design... It's difficult to decide what to go with sometimes. I mean, there are so many methodologies and one developer will claim this way is better, another will claim that way, etc. etc. It sounds to me like you have a relatively uncomplicated problem with not a huge amount of workflow and service requirements (please correct me if I'm wrong). It sounds like you might be implementing a reasonably straight-foreword windows app or web site. WINDOWS or WEB - two completely different technologies here!! Stateful and stateless. Nobody can truely answer you query without understanding more about your problem. However, I've implemented Active Record when business logic isn't too complex (you won't require the dreaded ORM's you speak of) and it has been very successful for me. I have also mixed some Active Record patterns with unrelational Domain Patterns as business complexity has increased - this has also worked. I read the other answers Don't confuse DTO's with Business Objects. DTO's just hold data(fields) and don't implement behavior, but Business objects do implement behavior and usually have a method to persist itself, by implementing a Save method, and calling through to a data layer/tier. Developers like to give advise but do your own research and when you've decided your route - implement it properly, that's my advise. I'm going on a bit aren't I :) I've recently created a couple of blogs and I've already written an article about the Active Record Pattern[^] (I've turned it in to a Domain Record Pattern) and I'm going to be writing a lot more about design. It's interesting to see what kind of questions people are asking. I hope you get chance to look at my blog - and please comment!!! Here's a recommended read for you. Microsoft .NET: Architecting Applications for the Enterprise[^] and it's not too heavy either. The article I've posted on dotnet-notepad are just notes (the blog is literally a notepad of ideas). My in-depth articles are going on