N-Tier C# Master Detail member

I am using Visual Studio 2010, Sql server Express Edition & C#.

I have develop a simple Master Detail application (mostly with the help of experts help from this forum) An Order system, and now I want to go one step further from simple application to N-Tier version.

Did some search on net and came up with Tutorial which guides me enough to create Order class which contains methods: -DataTable GetOrders(int OrdId) Retrieve order based on ID provided -int SaveData(string CustID, DateTime ShpDate, DateTime OrdDate) To save the order, This method has all Insert, Update, Delete command in it, using SqlAdapter.

Following the same pattern I've also created OrderDetails class for setting up line items for each order. OrderDetails also contains methods GetOrder & SaveData...

I've created DAL class for data access ofcourse, purpose of which is to provide Database connection and execute Sql commands or stored proc.

As mentioned in my question, I've created Order class which will access DAL class and Get and Save Order..

The problem I am facing is from OrderDetails class...

My approach is: On the Winform (which is I think Presentation layer) when user clicks save button It should do the following:

1-Create Order class instance (for eg. Order od = new Order()) and then call Order class SaveData method by providing parameters: Like od.SaveData(OrdId,CustId OrdDate, ShpDate)

Which then ultimately save the order Master data...Order master is bind to DataTable.

Now the problem: How should I save OrderDetails...which is in DataGridView name dgGrd, dgGrd is also bind to DataTable.

OrderDetails also have SaveData method which take parameters (ProductID, Quantity, UnitPrice)...How should I call SaveData method within Order class? How should I pass whole DataGridView DataTable to SaveData method of OrderDetails class?

I will be very much appreciate if you could help me to line up my coding, perhaps anyone could provide a sample? showing N-Tier Master Detail...I am still at beginner learning stage...And still doing lots of net searching for answer..

Thanks in advance

Ahmed

I'd start with samples, which you can choose from here

Thanks for reply, But those samples doesn't cover the scenario I am looking for...and most examples uses Entity framework which in my scenario is not applicable...

Could search the web: http://www.planet-source-code.com/vb...6528&lngWId=10

Already download it few days ago ...and trying to digest it...but meanwhile can you suggest any solution specific to my problem?

Quote:

---

Originally Posted by ahmed_one

Thanks for reply, But those samples doesn't cover the scenario I am looking for...and most examples uses Entity framework which in my scenario is not applicable...

---

Why do you believe Entity Framework doesn't apply?

Quote:

---

Originally Posted by Arjay

Why do you believe Entity Framework doesn't apply?

---

Becoz I am not using Entity framework

Quote:

---

Originally Posted by ahmed_one

Becoz I am not using Entity framework

---

You should consider using it rather than some out of date approach.

Quote:

---

Originally Posted by Arjay

You should consider using it rather than some out of date approach.

---

You are, of course, correct, but I think the OP is not really looking for an existing solution/framework, and rather wants to learn and understand the inner workings of such architectures.

@OP:
Before I go into details, let me just make sure you understand this first: in N-tier architecture, the tiers themselves are logical constructs - the way that the design of the application is logically organized; when actually implementing the tiers, the boundaries between the tiers may be rather diverse. Some of the tiers might be packed within a same program (tier boundaries being class interfaces, or maybe compilation units), while others might be distributed over a network (database here, server there, client on another place, etc.). So, it doesn't all have to fit in a single desktop app, nor is it required for all the tiers to be physically separated - it is a matter of organization, resources and requirements. Also note that, while it is a valuable architectural principle in general, when it comes to more involved design approaches, they often seem like an overkill for simple data access and manipulation scenarios, and that's because they are - their value is in coping with complicated business applications which require a lot of integration with systems that are already in place, and where, among other things, the presentation logic may be rather complex.

Now, to your question. What these frameworks do is, they try to make an object-oriented representation of the data from the database, to enable programmers that use them to work with objects as usual, and then they internally map these objects to the data tables when appropriate. But, the OO representation is normally not the exact replica (or 1-to-1 mapping) of the database itself; instead, objects are modeled in a more natural way, to represent relationships between various entities in a way consistent with how you normally code classes and objects. This is usually done automatically by some sort of a tool that generates the code for you from the database schema or something along those lines.

In your case, a reasonable logical design for the Order and OrderDetails class would be that an Order contains & owns an OrderDetail instance - as a member variable. If you do this, then when you can change SaveData() method of the Order class to also call SaveData() of the associated OrderDetail object.

Now we come to the funky part - how to make all this ultimately update the database, right? If I understood you well, you want for the Order and OrderDetails objects to update some other objects (like a DataGridView), that will then in turn update the data table via binding? However, if these other objects (like your DataGridView) are a part of the presentation layer, then we have somewhat of a problem here, because in that case you are trying to combine two conflicting approaches to data access together. This is because, if the application is setup that way, the (windows forms?) data binding mechanism practically bypasses your business/application logic layer (that is, the layer that conceptually contains the Order and OrderDetails classes), and communicates with the data access layer directly. This is bad because this prevents the business logic layer to do it's job, and that's to enforce the rules that govern the relationships between entities, their validity, acceptable states, etc (what we call business rules).

When it comes to the presentation layer, the ideal is to make it so that it is oblivious to the business rules and to relationship between business entities, and even to the presentation logic itself (presentation logic is about things like - "if this check box is clicked, what should be enabled/disabled", stuff like that; application/business logic is, on the other hand, about what the application should do behind the scenes in accordance to the requirements). So, the idea is to make the presentation layer as "thin" as possible - just a bunch of controls on the screen, without almost any knowledge of how they are to behave, or how they are going to be used. The clicks and button presses and such are instead delegated to some other object (or set of objects) that then "make sense of it" and update the view accordingly on one hand, and communicate with the data access layer on the other. However, if the presentation layer is relatively simple, these responsibilities often end up clumped together to varying degrees. For more info, search the web for the Model-View-Presenter (MVP) architectural pattern (and for a WinForms-targeted variant of it, see MVP-VM).

Now we come to the point: with things like MVP, the boring part is the boilerplate code that's responsible for the communication between the presentation layer (the view) and the model (the thing that holds your business objects (like Order) and business logic) on one hand, and on the other hand, the boilerplate code that connects that to the database, or to wherever the data is stored. That adds a lot of extra work, but it pays of in the long run. Still, people don't want to do it if they don't have to, so you generally want to exploit helpful features of the language and the environment you are working in, if you can - like data binding frameworks, etc. Another technique is to use (or write) tools that will auto-generate this boilerplate code for you. Sometimes, there's both.

Finally, what you want to do amounts to this: you want to have a view (which might potentially delegate handling of the presentation logic to a specialized object or objects), and communicate from it the user input and commands to the application/business logic layer, which will be in charge of actually doing the work that is the primary purpose of the application; it will in turn, when appropriate, prepare all that data and send it to the data access layer, which will finally put it into whatever data store it is supposed to go to. And, if possible, you want to setup data binding and/or events to connect these layers, so that you don't have to write the boilerplate code yourself.
This is important, because your data binding setup should be geared towards facilitating what's outlined above, and not towards what the usual, general purpose data binding tutorials tell you to do.
Sometimes, though, setting up data binding for a specific part of the system may turn out to be more cumbersome than writing the boilerplate code yourself, so in such a case, writing your own code is a valid option.
Also, you don't have to connect/databind each and every data object; you can have a facade object that references several data objects and handles data binding for all of them, etc.

So, regarding connecting all the different components and tiers, check these out (assuming you are working with WinForms here):
Walkthrough: Connecting to Data in Objects (Windows Forms)
Object Binding in Visual Studio
Tackle Complex Data Binding with Windows Forms 2.0
For some of these you can use wizards, but you can also write the code "manually".

If you want more specific help, then post some code, and maybe some UML diagrams, so that we can see how you've set up the whole thing.

Do check out the code you downloaded earlier, the one dglienna linked to - but note that as soon as you run the app a message from the author pops up saying: "The main purpose of this experinment is to create an n-tier coding [...] without creating an object model classes to cut-off development time.".


All that said, when actually developing an application to be used in the real world, it is better to use an existing framework, such as the Entity Framework, then to reinvent the wheel yourself.
Remember what I said that the most annoying and boring part of this is writing the boilerplate code to connect the thing together? Here's a description of Entity Framework from this site:

Quote:

---

Entity Framework (EF) is an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. It eliminates the need for most of the data-access code that developers usually need to write.
[emphasis by me]

---

That's the whole point.

Quote:

---

Originally Posted by TheGreatCthulhu

All that said, when actually developing an application to be used in the real world, it is better to use an existing framework, such as the Entity Framework, then to reinvent the wheel yourself.
Remember what I said that the most annoying and boring part of this is writing the boilerplate code to connect the thing together? Here's a description of Entity Framework from this site:

That's the whole point.

---

Exactly, and that is what I was getting to by mentioning the Entity Framework to begin with.

It's tough when learning to know what to focus on. And you have to be careful about learning technologies that are already obsolete. On one hand it's good to start with the basics and work your way up to modern approaches. However, time is limited, so at what point do you start? Do you start in C with ODBC? With ADO or ADO.Net? The Data Table approach? Sure, it's good to have the background on older technologies, but I wonder if it is at the expense of missing out on more productive approaches like using the Entity Framework? It might be better to ramp up on EF and LINQ and end up learning the current app tiers.