|
Leslie Sanford wrote: I was wondering what the best practises are for stored procedures. Basically,
I'm still struggling with a kind of code explosion that occurs when writing code
that's related to the database. In the end, what I need to do is move data into
and out of the database while sometimes performing transformations and doing
error checking along the way. I've found over and over again that it takes a lot
of code to do this.
Learn to use existing frameworks. Dynamic ones or generated static ones.
Database code is often something that is very amenable to those types of implementations.
Myself I have been write database layer code generators for years.
Additionally other common functionality is easily assigned into the same layer generation types. For example one can generate field generation code that validates such things a existence, length and even pattern for use in things such as GUI code.
Some of this is something that you are more likely to gain an advantage by learning to write your own code generators.
Leslie Sanford wrote: I'm curious if stored procedures are a good way to abstract out of code such
things as queries, inserts, updates, etc., and move them into the database
itself.
Yes. For the same reason that one create any layer code - to abstract the user from the implementation.
Leslie Sanford wrote: I'm finding that database programming is largely procedureal in nature, so I'm
not finding my experience with Object Oriented programming and patterns to be of
much use.
Relational databases have a very long and successful history. For a reason.
So avoid the inclination to even attempt to make it OO. There are in fact ways to do that and it is unlikely that it will lead to positive versus negative results.
You start with a data model. Then you use stored procs and the database layer to translate the relational model into an OO model. Just as you do with any other translational layer.
As a final note don't get to wrapped up in where the "best" place is for business logic. As an example don't avoid uniqueness keys in the database simply because that is expressed as a business rule. The database can implement that just as well, and probably better for standard business cases, versus attempting it in the database layer.
|
|
|
|
|
All,
Recently I have been doing a lot of thinking about where to invest my training time over the next 5 years. I am perplexed.
I do primarily Winforms development now, I have a couple of commercial products, with some ASP .net. I am ready to update my skills and have been trying to decide where to place that investment. Should I do WPF,Silverlight? Should I do Mono? Should I just give up on MS and do C++?
I think the reason for the quandary is that in all my research there are a number of people saying the MS is going to abandon this or that technology. I am all for learning what I need to in order to do my work but I don't have the desire to learn every piece of crap that MS puts out.
I am a pragmatist and I want to learn to a level of excellence what I need to do my work. I have a couple of large commercial products that I want to position on the correct platform but I can't be rewriting 100k lines of code at every MS whim.
Recently I have been thinking about just moving everything to C++ but that seems like a daunting task.
Anyway any constructive suggestions would be appreciated.
|
|
|
|
|
Conversations that I've had with some of the MS insiders recently suggest that the following are worthwhile technologies to invest in:
HTML 5 (this includes the WCF vNext, CSS 3, JavaScript and ASP.NET MVC)
Silverlight
WinC++
WPF (it's still going strong).
With HTML 5, you'll have a very transferrable skill because while there's an MS flavour, HTML 5 is not MS specific.
|
|
|
|
|
Thanks Pete. That was a good info to have. 
|
|
|
|
|
You're welcome. I just wish MS would state their position clearer, then there wouldn't be this fud.
|
|
|
|
|
What exactly is meant by "WinC++"? I'd be interested into the background of this recommendation... In my (humble) opinion, the further away you get from Win32 APIs (assuming this is what you meant) the better off you might be in the future. Or did you mean the plain ANSI C++ as implemented by Microsoft?
|
|
|
|
|
If you want to know more about WinC++, this[^] article is a good place to start.
|
|
|
|
|
Unit Testing and Test Driven development are becomming more mainstream these days so definately improve in that area if need be. There is a lot of ASP work around so that could be a good direction but as a Winform developer, you may find Silverlight/WPF a more natural progression. I wouldn't throw your .NET skills in the bin. I'd work on developing them in new directions. Also LINQ, WCF and EF aren't looking like going away any time soon.
"You get that on the big jobs."
|
|
|
|
|
Porting your well-running apps to a different technology/platform is something I wouldn't suggest. It has a very heavy price that does not justify the benefits. Continue to develop/support your apps in their current platform as long as they're good to go. Porting to a different platform is something to be considered only when the current platform does not support the features required, then it makes sense to do a complete rewrite.
|
|
|
|
|
Personally to me, this is a very interesting question. Many moons ago (over 15 years), I had to make a decision similar to this. Of course, many moons ago technology choices were a little limiting with defined camps. So my decision was based on what I enjoyed doing the most? To which technology will can I see myself doing every day?
Back in the day, many may laugh and some reminisce, I was mainly doing DOS based development and before any type GUI based development. The ole command line with line numbers in BASIC when the IBM/Intel based PC was a relatively new technology. Development languages were emerging and technologies growing in all directions. Being a little seasoned, already in the in industry for several years, experience with microcomputers and main frames. I did a little of this and a little of that from desktop publishing, database development and applications on the various platforms, the question was still what do I enjoy doing every day?
I have digressed, but to make a longer story short, I did pick a technology I enjoyed. I learned every aspect of it inside and out. Like looking through the source code, understanding its design structures, how the entire system ran and relationships between the systems. I understood the system to the point where, I could make the thing sing and a cup of coffee. And I learned not just the technology or system, but I also picked up design, architecture and the appreciation of how development is an art form.
Not knowing your background the answer would be make a choice that you will enjoy doing.
|
|
|
|
|
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?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
