|
im developing a address normalisation engine in c#
its a part of it.....
the quieter u become more u hear
|
|
|
|
|
Dear users,
How to add icon in control pannel using c#, by which we can set own application settings.
Azad Yadav
|
|
|
|
|
Hi,
When you use the CodeProject search facilities (see top of most pages here) you would easily find several relevant articles including this one[^].
|
|
|
|
|
Dear users,
I want to know how to create window user programmatically
Azad Yadav
modified on Friday, January 16, 2009 11:35 PM
|
|
|
|
|
Form frmName = new Form();
frmName.Show();
|
|
|
|
|
Hi everybody!
Is there any idea how to get new explorer menu design for my project? May I know any website I can find.?
Appreciate your help!
thx
flowerppk
|
|
|
|
|
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?
|
|
|
|
|
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/
|
|
|
|
|
Interesting! However, I learned the pattern from a very successful book named C# Business Objects. The Save() method of the business object simply does this:
public void Save()
{
CustomerManager manager = new CustomerManager();
manager.Save(this);
}
The logic for object persistence is in the DAL and not in the business object. I will read about DDD but it seems as the more I read, the more I find out that it is all a matter of opinion. It took me long to learn the above pattern (known as 3 Layered or N-Layered) and I had some fuzzy areas which I wanted to polish up. But you are guiding me in a different direction which is fine but I also want to clear-up my confusion that I have in this area.
You also answered my question on the Design and Architecture forum and gave me a lot of information--and I thank you--and suggested I should use O/RM but I want to learn how to do this myself for learning purposes. I do not like abstraction unless I know what it is that is abstracted...I am curious.
|
|
|
|
|
I also read the book C# Business Objects, by Lhotka, and I implemented an architecture very similar to it (I based our custom architecture on his CSLA). It turned out to be an absolute maintenance and management disaster.  Just a word of warning.
|
|
|
|
|
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).
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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[^]
|
|
|
|
|
Found this[^] - you have to register (painless and free) but then you can download it.
Might be worth a look?
DaveBTW, 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.
|
|
|
|
|
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 csCoffee[^]
Pen and Paper before Visual Studio. Hope I've been helpful.
|
|
|
|
|
I a noob, just to get that clear. Here is what i wanna accomplish.
I retrieve a user id via a connection string, i want to used that id to call a stored procedure that then bring back the user's fname, last, add etc in my labels, do any of you have any example or guide on how to do this, guys i really need help and thanks in advance.
Ferron
|
|
|
|
|
So you have "in your hand" a user ID and you want to be able to send it down to a stored proc to lazy-load[i.e. "load on demand"] the user's data?
There are several things that could be done, but the solution to this problem can be very rudimentary or quite complex. It is important to know what the kernel of your code-base looks like in order to cater a solution to your specific app.
What have you tried so far? What isn't working?
"I need build Skynet. Plz send code"
|
|
|
|
|
well i know how to create the query string. Just need to know how to create the stored procedure and place the data in the necessary labels
Ferron
|
|
|
|
|
do you know where i could get a good guide or can you point me to a online tutorial that can do this, thanks guys
Ferron
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
