|
Leftyfarrell wrote: What is the best architecture to avoid/work around this problem?
Don't know how you will take this, but my opinion will be as follows,
The common will contain only the DTO structure of the data you are concerned about. for example you common can have a class roughly something like
namespace Common {
public class SupportedCultures : Collection<culture> {}
}
ICultureDal { Common.SupportedCultures GetSupportedCultures();}
IBusinessServices
{
Common.SupportedCultures GetSupportedCultures();
}</culture>
now you client application will use the IBusinessServices to get the list of culture and may be cache it as needed to avoid further business calls. (you can also cache it at your service layer)
Moim Hossain
R&D Project Manager
BlueCielo ECM Solutions BV
|
|
|
|
|
That works for core concerns...business concerns. But the original question was in regards to cross-cutting concerns. Cross-cutting concerns are things like logging, validation, instrumentation, security, context, etc. These don't really fall into the categories of business services or DTOs. Cross-cutting concerns are one of the major pain points in software development today, and the driving force behing things like AOP, Aspect-Oriented Programming. AOP aims to privide a mechanism to separate cross-cutting concerns from your core concerns, and apply them in an alternative, configurational manner (possibly adjustable at runtime).
|
|
|
|
|
Are you certain the OP's topic of loading a collection of supported cultures fits that category? Doesn't seem like it should. I am always suspicious that a static helper class is a indication that some refactoring might be in order.
Leftyfarrell wrote: So I create a static helper class
led mike
|
|
|
|
|
Well, my other response described my recommended solution. I agree, statics are something that should generally be avoided. An area where statics can be helpful is in creating simple facades that wrap up complex frameworks into simpler ones. There is always a cost involved in every decision like that though.
Leftyfarrell wrote: The heart of my question really has to do with cross cutting concerns like Logging, Exception Handling, Validation, Instrumentation etc.
The above statement is what I am basing all of this on. Cross-cutting concerns are those that permate every aspect of your application, all layers, all levels. They are difficult to neatly package up into well-isolated "areas" like a presentation or business layer, a service, whatever. Lefty's validation loads localized messages from a database, caches them in a static class, and spits them out whenever a validation error occurrs. Even though localized text is involved, it doesn't change the fact that were talking about a cross-cutting concern. Its just a cross-cutting concern that happens to access a database. The choice to use a static class to hold the cached localization data is probably fine...perhapse even ideal, if the messages rarely or never change. Data that seldom changes is technically static anyway.
|
|
|
|
|
Jon Rista wrote: They are difficult to neatly package up into well-isolated "areas"
I guess I don't understand, I have never run into any unusual problems isolating the concerns you specified. Here I use the word isolate regarding both a design and packaging perspective, which avoids any circular issues.
led mike
|
|
|
|
|
I mean it from the perspective of use I guess:
When you write a Controller, you put that controller in a project that is part of the "presentation layer" of your application.
All controllers will be in the presentation layer...you won't have any in the business or data access layers.
You have neatly grouped all your controllers into a single area, and they will only be USED by other things in your presentation layer.
When you write a Business object, you put that service in a project that is part of the "business layer" of your application.
All services will be in your business layer...you won't have any in the data access layer or in the presentation layer.
You will transform business objects or graphs into DTO's for transfer accross the wire to your presentation layer and back.
You have neatly grouped all your business objects into a single area, and they will only be USED by other things in your business layer.
Cross-cutting concerns can not be isolated like that:
When you write a logging framework, you put the logger class and its support types in a "shared" area.
Your logging functionality is neatly encapsulated in the shared area of your application.
Your logger will be used in MANY places, accross your layers, including presentation, business, and data access layers.
Your logger's use is not neatly grouped, it is scattered throughout your application, and there is no way to keep usage of logging, a cross-cutting concern, isolated to a single area of your application.
|
|
|
|
|
Jon Rista wrote: Cross-cutting concerns can not be isolated like that:
Ah, yes because then it would not be cross-cutting. I thought we were talking about the library design creating the circular problem not the user code creating the circular problem. My bad.
led mike
|
|
|
|
|
No problem. I think I kind of confused the issue anyway by using the term "packaging". :P
I've been delving deep into AOP with the PostSharp framework lately, so my perspective on things is a bit skewed from the norm right now. From the AOP perspective, aspects kind of referr to usages. If full AOP capabilities existed in .NET, you could "package up" aspects and apply them to multiple points in your code using external means. This allows a more appropriate separation of concerns, allowing you to neatly isolate cross-cutting concerns from core concerns. PostSharp doesn't yet allow such flexibility in applying aspects, but its getting close.
|
|
|
|
|
That sounds cool. It was nice to talk with someone that can speak design for a change. Thanks.
Have a great weekend ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
led mike
|
|
|
|
|
led mike wrote: It was nice to talk with someone that can speak design for a change. Thanks.
Agreed!
|
|
|
|
|
Great discussion guys. Thanks for the comments and sorry I was away for a while... this tab got lost within 40 others in my Firefox window...
For now, what we wound up doing is something like this:
Global.Common assembly contains base classes for Validation.
Logic to load validation error message strings is different depending on what "area" of the application you are calling validation from, ie. UI vs. BLL
Each of our "areas" also has an assembly for common code (shared among the assemblies in that area) so we have:
UI.Common and
BLL.Common
For the validation example... we created a validation class in UI.Common that inherits from Global.Common, but provides its own implementation that loads the message strings from our BLL by calling through WCF.
We will create another validation class in the BLL.Common that inherits from Global.Common, but this implementation will call the BLL methods directly to load the message strings, without going through WCF.
This way, the cross-cutting concerns are kept within the 3 Common assemblies and uses a provider model idea for the loading of message resources.
|
|
|
|
|
Hello,
I am creating a windows service which performs 20 operations based on some condition. So at one time one process will be executed.
All these 20 different tasks are separate assemblies added to the windows service. The objects and the call to the assembly will be made only when needed.
For example:
Case "findcustomer"
create object
process
Case "findVendor"
create object
process
Is this approach a good idea? Also I want to know what needs to be keep in mind related to design of this service.
Regards,
Pavas
|
|
|
|
|
Make sure you work out what the Start, Stop, Pause and Resume methods that the Service Manager allows to be called on the Service will actually do. For example to call Stop, do you need to know which 'process' you are running so it can be stopped? Does it take time to stop? Or maybe you can't tell if a process is running so then you need to find out? Do you realy need Pause and Resume? If so what will they do?
|
|
|
|
|
Why the subject is saying about Web Service, you are actually designing a windows service..?
Moim Hossain
R&D Project Manager
BlueCielo ECM Solutions BV
|
|
|
|
|
That is a mistake. Sorry for that.
Regards,
Pavas
|
|
|
|
|
My job role has changed significantly as we have started offshoring most of our coding. Since I have domain knowledge and good relationships with the client, my responsibilities have been relegated to mostly doing design work. We are getting ready to start a fairly large project and I will be overseeing 3-4 offshore developers.
Previously, the company I work for has not placed a lot of emphasis on documenting design other than documenting UI and database design, etc. It is critical that designs now be detailed enough that offshore developers can code new design with minimal oversight.
I have two questions:
1) What type of training materials would any of you suggest? Specifically ones that focus on communicating design (all other parts of the SPLC are managed quite well).
2) What tools would you suggest to aid in this process?
Thanks in advance,
Kevin
|
|
|
|
|
I'll suggest that you start off by investing in a decent enterprise architecture tool. This will help you to document sequence diagrams, activity diagrams, etc. When it comes to communicating design, we find the RUP process to be helpful - use cases, detailed designs, storyboards, etc... You may want to read up on RUP to get a better understanding of what you will be producing.
|
|
|
|
|
Read books on Software Analysis and Design. Some tools which come to mind are Rational Rose, MS Visio, and buy a roll of paper from a meat market (yes the one they use for wrapping meat). You can sketch diagrams using this paper.
|
|
|
|
|
Thanks for the info. I've been introduced to Rational in the past, but I'd be fighting an uphill battle to obtain licensing for it. We are pretty much limited to Microsoft products. I know that there are a lot of features in Visio that I'm not aware of, so that might be a good starting point. Is there anything in Visual Studio Team System that would be helpful? I've watched some demos on the product and I see that it has static code analysis, profiling, testing support etc, but it doesn't appear that it would be helpful for what I'm looking for. Automatic code generation doesn't work well for us either, since we are dealing with existing c++ applications and we generally don't create a lot of new classes.
Drawing stuff out on paper (or a white board) is always a good idea. With this offshore design, we are finding that we need a high level of detail in the design. I think what would be helpful would be able to define classes and their member functions and include pseudo code with the member functions. I'm trying to get away from Microsoft Word. I find my self spending more time fighting Microsoft Word than I do thinking about design. I know Rational has some ability to generate some documentation. I think that alone would boost my productivity considerably.
|
|
|
|
|
Try StarUML which is an open source and really worth it.
|
|
|
|
|
Thanks. I took a look at StarUML. It feels like a good tool, but I seem to be finding UML to be quite unsatisfying. It seems too generalized. When I think of Object Oriented design, I still think in terms of programming. I think of words like inherits, derives, uses, interfaces, references, etc. UML allows you to model this infomation through generalizations, associations, compositions, etc, but these terms seem to generalized and difficult to understand. I would think that if I was creating a class diagram, I would want to use programming terms.
What I think would be a great tool would be if you had essentially a class diagram. In each class, I could then define members and methods. You would then be able to described each member, describe the purpose of each method. Then it would be nice to be able to include psuedo code inside the class methods. This would all be done inside of some modeling environment.
Then, when I'm done, I could generate a word document that would look similiar to what an API documentation would look like, complete with the descriptions and pseudo code. Then I can hand off the document to programmers that could implement it.
I could do all this in MS Word, but it takes too much time formatting and fighting MS Word. I also have to do everything twice. Create the diagram in Visio, then write everything in WORD. Visio has an report tool, but it fills the document with UML lingo. It looks as if you can create Word templates for StarUML, but I couldn't figure out how to document the operations, nor do I have the first clue on how to create a suitable template.
Does such a tool exist?
|
|
|
|
|
I did find the "Methods" button in Visio. I've also found that I can customize much of what goes into the report document. I might be on to something here.
|
|
|
|
|
Lets say I have this hypothetical database (the one I am dealing with is much bigger as you probably can imagine or guess):
Customers
---------
ID
Name
Address
ShippingAddress
OrderID
Orders
------
OrderID
Date
LineItems
---------
ItemID,OrderID
Quantity
Items
-----
ItemID
Description
I have many applications which need customer's ID, Name, and Address, Items' ID, Description. Is it better to create a library which can load the customer ID, Name, and Address and same for the Items by invoking a stored procedure or is it a better design to have a stored procedure which will get whatever I need for the specific application. For example, one application might need customer's id, name, and the number of orders and it might need what items we carry. However, another application might need all the columns of customer and Items. Because too many applications need customers' ID, Name and Adddress, should I create a static class class with static method which invokes a stored procedure and gets the information and if I need more information in other application I simply get those as per need basis, or should I just skip creating a static class library and get everything when I need them by invoking some stored procedure which returns all I need.
If I create a library, the advantage is I can use it in many applications and get the extra columns if I need to (but at least a few apps will not need the extra columns so simply calling the static methods will do the job). However, if I need other columns then I have to get those separately. If I do not create a library, I do not have the advantage of code reuse but I can get whatever fields I need and load them as need for the application all in one shot. I am wondering which solution is more advantageous over the other? Or, is there a better way?
Thanks,
|
|
|
|
|
Some opinions:
I think you should use stored procedures or views (which ever you prefer) to get the data. You can combine several needs to a single procedure, but I would think the procedure output as an interface (technically not the same as in .Net but the idea). If there are several needs which are almost identical and they don't change the logic of the output and there's no performance penalty, I would combine those.
About the static class. This is basically caching and it's a good way to ensure performance. However you must consider when to refresh the data in the static class. When and how are the modifications fetched to the class. You might want to use SqlDependency[^] if it's SQL Server you're using.
One thing you didn't mention at all was security. I don't know if it's an issue but is it ok that all the data can be used by clients. If not, that consideration should be part of the process when you think what procedures you'll create.
|
|
|
|
|
Security is not an issue. What I am trying to find out is:
Is it a better idea if I make a library which other developers can use by simply calling the static method which will return CustomerID, Name, and Address. The static method will return a DataTable by invoking a stored procedure. If the developer needs other fields they can worry about that themselves and retrieve them. Should I create a library or am I just wasting time doing this? The thing is many applications need these fields so I thought a library will ease things up.
Of course, the alternative is to let every developer create their own DAL and stored procedures and get whatever they need. The problem is 10 different applications may simply need CustomerID, Name, and Address and thus code will need to be written within each app's DAL. This is a waste of time. What do you think?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
