|
I completely agree with you and know where you are coming from. I too 'back in the day' enjoyed every day. Today is a bit different though. We use to be able to learn a language and be pretty sure that we could compete for 5 to 10 years and we could master our craft. Today sadly it is not the same IMHO. Everyday MS gives us 14 new things that we MUST learn... **RANT OVERTED**
I have loved everyday of my life as a developer/architect for the past 25+ years. I have no intention of changing just trying to get a feel for where to bet my training time over the next 10.
Thanks
JD
|
|
|
|
|
what is a data access layer,business logic layer?
|
|
|
|
|
|
Create a class library - BusinessLogic
Create a class library - DataAccess
Now, from your UI, use the object model and pass on to BusinessLogic project class. This class is a Business logic class. Do the changes as per your need here.
Now, pass on the changed data from business logic class to dataAccess project class. In this class, use ADO.NET and pass on the needed values to Stored Procedure.
For getting back data, it will be transferred from DA to BL and then BL to UI layer.
Have a look at these, explaination with samples:
3-tier architecture in C#[^]
3-Tier Architecture Examples[^]
3-Tier Architecture in ASP.NET with C#[^]
|
|
|
|
|
As their name implies it.
A data access layer has the responsibility to access data sources (e.g. a data base). Possible implementations of that layer may contain SQL statements.
The business logic layer contains all the logic of the domain you're in. It gets the data needed for its business processes by using the functionalities of the data access layer. It doesn't care about how the data is grabbed from a source.
The data access layer in contrast is not able to acccess the businnes layer (which lays "above" it).
|
|
|
|
|
I've been perusing web documents about dividing up an application into three blocks, the MVC pattern, and it looks like something that would help me to organize a project I've been working on for some time. If I'm understanding what I'm reading, the View portion consists of a collection of user interface elements (forms, in my case) which emit Events in response to user actions. The Model contains all the real functionality, triggered by commands from the Controller, and also emits Events to signal changes in state. The Controller seems to act as a switchboard, monitoring and responding to Events generated by the other two sections, and coordinating everything. That's so perfect for what I need to do that I really want to try it.
The question is, and pardon me for being naive, should each of these sections be implemented as separate projects within a solution, or simply as folders within a single project? The default in VS is to simply create everything under one solution, and as the number of classes grows, I find myself easily lost among the many files. Some level of organization is clearly needed, but I don't know which to choose, or what the implications of either choice might be. Although it adds some overhead, I'm leaning toward creating separate projects. My thinking is that, in some similar future project, I may be able to reuse a lot of the structure in the View and Controller elements, though the classes may change.
For example, right now I want to read a bunch of text data, parse it, classify the different lines into keepers and fluff, then convert the text of the keepers into records and save them to SQL Server. This is one I've already described, reading electric power meters, saving the hourly values, and later extracting total consumption for user defined time intervals. But next month I may want to do much the same with water well flow rates, chlorine residual levels, and pH readings. It's much the same job, so theoretically I should be able to reuse much of what I've done before. Since my time is so very limited, reuse is a major issue for me.
Which approach would you recommend, and why? Will I be creating unforeseen problems for myself if I use the multiple project implementation, or might I actually realize some benefit by creating projects that I can use as starting templates for future designs?
Will Rogers never met me.
|
|
|
|
|
I just can tell you about how i have done it (so far at least). Usually i just divide one solution by subfolders for the different layers of the architecture e.g. View, Model, Controller.
If for example you look at the ASP.NET MVC approach you'll find this in a similar way. Just by the path of the class file you could tell lets say a View from a Controller. Another benefit is, if you're are consistent in Naming your files you can simply by this convention tell which Control belongs to which View.
In my opinion Reuse doesn't come from your project management but the class design itself.
Anyway i think it's easier to keep your different layers in one solution.
good question btw 
|
|
|
|
|
I'm developing a WPF app using MVVM. I have created a Models project and a Data Layer project. They are two seperate projects because later on I'm going to move the data access into a WCF service. The Data Layer creates, populates, and returns model objects.
The question is, assume a one to many relationship such as an invoice header and invoice line items. The InvoiceHeaderModel has a list property of type InvoiceDetailModel. Where's the right place to populate this?
If you do it in the model, maybe with lazy loading, then you create a dependency between the Model project into the Data Layer project. The Data Layer project knows about the Model project, but not the other way around. And, if you lazy load the child properties, then you have code in the models.
The only other place I can see it would be to have a method in the DL, say GetInvoiceDetails(InvoiceHeaderModel Header) that gets the details for the invoice and populates the header model's details property.
What do you think?
Everything makes sense in someone's mind
|
|
|
|
|
This is how I would do it:
The WCF application will have the model project and will serve the same responsibility through parsers or whatever you like to call them. Parsers will translate the return value from the database to a specific object. This object will then be returned to the front end.
The front end, will still have it's own MVVM. Here the data layer (or some other name) will make calls to the service operations and will translate the service model to the UI one. I have assumed that the UI model is different from that in the services.
Hope this makes any sense.
|
|
|
|
|
I was thinking that I could pass a bool into the GetInvoices method on the data layer that determines whether or not the invoice details property gets populated. This way I could get back either a list of invoices with all details, or just a simpler list of headers only. And, with this design, all the code is in the data layer instead of the models.
What do you think?
Everything makes sense in someone's mind
|
|
|
|
|
Sounds good to me. Model should not be doing that work at all. 
|
|
|
|
|
Completely agree. Model should only be in charge of representing the data, and probably relationships between entities, let the ViewModel and Presenting interfaces translate the data according to their needs.
"Whether you think you can, or you think you can't--either way, you are right."
— Henry Ford
|
|
|
|
|
I have 2 major project in my Silverlight apps. WCF with the model and the dal (controller). The models have no relationships, they don't even have adorners yet but that will change. The model does however have all the fields from a view rather than a table. The DAL does all the decision making.
All access is via stored procs (this maybe old school for some but it is the way I work) and most selects return a view (this being and extended table and matches the model).
The second project is purely UI with view and viewmodel folders (among others). I also have a utilities project that is used across projects and is still in constant flux.
I am continually finding that the standard controls all seem to be missing something and therefore we have moved to the Telerik control suite which I highly recommend (expensive and it adds 1mb+ to the silvelight client download).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I would just like to run my business process, for registering new members on a web site, by the readers here and invite comments on my first of such a design.
My Member class has PendingReplyId (a GUID) and PendingReplyRequestTime properties. After validating details of a new member, such as unique username etc. I create a new member record with a new reply id and request time, then email the new member a URL containing the reply id. When the member clicks that URL, the reply id is passed to my confirmation page. There I try and find a member based on the ID, check if the ID has timed out, and if all is well I mark the member as Approved.
What say you all? I know I should really factor out the reply id's and times into a separate table, but they are only ever used for Member replies, and only for one task at a time. What else could or should I be doing differently?
|
|
|
|
|
I have develop a web based Accounting and Inventory Software. How I can Market it?
|
|
|
|
|
Create a website for it!
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!
The unofficial awesome history of Code Project's Bob!
"People demand freedom of speech to make up for the freedom of thought which they avoid."
|
|
|
|
|
Hire someone to sale/market it.
This is not a technical question and thus it is not the right forum for such question. This fits in for a discussion and pick Lounge or similar forum for the same.
|
|
|
|
|
What is a book that comprehensively treats design principles such as:
1. Open/Close Principle
2. Liskov Substituion Principle
and others like these. I know Heads First Object-Oriented Analysis and Design has a chapter on this, but is there a whole book dedicated to just design principles? Or at least a book that provides more material than Heads First. There ARE books available on design patterns but I can't find ones on design principles...
|
|
|
|
|
|
Code duplication really frustrates me. Is it just me, or do others feel the same? What I'm thinking about is when somebody has clearly copied a chunk of code, and then changed a few lines in the new version. Duplication seems to always cause problems.
Some people just don't seem to see the problems though. They will copy code without thinking about it, and give you a puzzled look when you say something about it. It always seems to be somebody else who either has to suffer or spend time refactoring it. In my opinion it's just a 'hack'.
|
|
|
|
|
Member 4487083 wrote: Is it just me, or do others feel the same? What I'm thinking about is when
somebody has clearly copied a chunk of code, and then changed a few lines in the
new version. Duplication seems to always cause problems.
It really depends what you're talking about. DRY just means don't repeat yourself. If the code you've taken is from the web, then modifying it to suit your needs is perfectly acceptable. I do agree that it's a PITA when somebody copies and modifies code that they don't understand (we see plenty of that in the forums).
|
|
|
|
|
Pete O'Hanlon wrote: It really depends what you're talking about. DRY just means don't repeat
yourself. If the code you've taken is from the web, then modifying it to suit
your needs is perfectly acceptable. I do agree that it's a PITA when somebody
copies and modifies code that they don't understand (we see plenty of that in
the forums).
Copying snippets from the web is usually ok. Although I would expect somebody to copy a block of code from the web and paste it in many places. Unless it's a simple, single line of code then it should probably go into something like a function/method. I don't think I've seen cases where people don't understand the code that they copy, but I'm sure it happens.
|
|
|
|
|
Member 4487083 wrote: I don't think I've seen cases where people don't understand the code that they
copy, but I'm sure it happens.
You obviously don't spend a lot of time answering questions in the forums here then.
|
|
|
|
|
Pete O'Hanlon wrote: It really depends what you're talking about. <layer>DRY just means don't repeat yourself. If the code you've taken is from the web, then modifying it to suit your needs is perfectly acceptable. I do agree that it's a PITA when somebody copies and modifies code that they don't understand (we see plenty of that in the forums).
In that case, you're repeating someone else. Having the same method repeated in your project would be a duplication, giving you two places to maintain that offer similar functionality.
I are Troll 
|
|
|
|
|
I know what DRY means. I was just clarifying it because the wording could have been taken that way.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
