|
Ok!
Thank you for your help!
|
|
|
|
|
Take a look at this.
If this is the type of state diagrams you are talking about then you can make 1 type of implementation as follows in code:
1) Create a class e.g. MyState.
2) Add a string property State with a private setter and a public getter.
3) Add a public transition method e.g. Transition that takes an argument e.g. Target
4) Let the transition method set property State to Target.
If you instantiate MyState, you have the means to encapsulate a state diagram into an object.
Identify the transitions in other code and let those transitions call Transition of MyState.
In this setup you have a state object that is able to report the state of others.
Sometimes you see MyState as a property on another object. Sometimes MyState is just part of another object.
The later means that an object e.g. MyFoo encapsulates its own state information, which is quite a virtue in OOP.
Example: As a OOP developer you expect that a File object is able to tell if its read-only or closed. You don't want to shop around by other objects to figure that out.
If MyFoo not only encapsulates its state information, but also its state transitions, then MyFoo becomes quite handsome.
In this case the Transit method must implement all possible transitions with their conditions and throw an exceptions (or similar), if it cannot make a transition.
If you let MyFoo make some transitions by it self then it becomes partly autonomous.
If MyFoo becomes 100% autonomous then make the transition method private.
Usually the Transition method is a set of methods e.g. File.Open, File.Close, etc.
Usually the State property is an enum or similar. Some OOPs prefer however the State pattern.
Regards,
Keld
|
|
|
|
|
Thats's great.
Thank you for the post!
|
|
|
|
|
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.
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.
In a way, this relates to a thread I created here a few months ago about database code. I'm trying to get a handle on how to deal with complexity. 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.
|
|
|
|
|
I believe that the database and the stored procedures, or functions should only be used to guard data constraints. So they can be useful when you insert data into one row that always needs to be verified against another table, when a foreign key alone does not describe the full nature of the relation. For example one row depends on a range of rows existings in a foreign key. Another good reason to use them is to guarentee sequential execution of data insertion or deletion across multiple instances of the application.
From what I understand from your question you might be better of abstracting inside the code first by generating generic classes responsible specific parst of the applictions communicating with the database.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
