|
Have a look at my article[^]
Carlos Merighe wrote: it appears that the Data Access Object Design Pattern is a good solution to separate a Data Access API from the business objects.
I would even say it is mandatory. It makes you think in smaller problems, which in turn makes you build simple and easy solutions to those problems. If you pile up everything into one problem/solution you'll end up with a huge mess.
Also it enforces re-usability, which leads to robust and stable code.
Carlos Merighe wrote: What is the best Design Pattern to separate data access from the business layer?
The one that fits you best. I'm not saying that so I can give you an easy answer. There is no "best" solution. Try out different solutions and see what best fits your needs and coding styles. Depending on the technology you can go old school as in my article or go the new way with LINQ or other technologies. Note that if you're in a company you probably want to use their way of working.
hope this helps.
|
|
|
|
|
You could also use the Unit of Work / Repository pattern for your purposes.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
i need design pattern which will do continuous monitoring and evaluating and then further evaluating after certain time period. Working on Windows platform. Need help how or which design pattern to use or what approach to use .
Thanks,
|
|
|
|
|
|
i want which particular is more suitable to scenario which i described.
-- modified 11-Feb-14 3:22am.
|
|
|
|
|
What do you mean which language? Design patterns are concepts, they are language neutral.
Veni, vidi, abiit domum
|
|
|
|
|
bymistake i typed it - "which language" .. i have edited it.. please see it.. I know design patterns concept.. looking for specific pattern suitable for my requirement.
|
|
|
|
|
You first need to do the requirements analysis and design of your application. You can then look at all design patterns and implement where they are most appropriate.
Veni, vidi, abiit domum
|
|
|
|
|
There is no specific design pattern for what you're trying to do. But here are some general pointers:
1. Observer pattern allows you to monitor an object by subscribing to an event and then taking an action when that event occurs.
2. Visitor pattern allows you to perform operations on an element's structure.
3. The Command pattern can be used to encapsulate the command you wish to perform on the monitored objects.
4. To do a periodic or continuous or repetitive task, you usually implement a Timer.
|
|
|
|
|
|
Hi All,
I need to design a system where-in there is lot of decision making and also system needs to be adaptable as and when required.
Looking into above criteria adapter n visitor design pattern come to my mind but not sure. Please suggest design pattern as per above requirement.
I need to develop system in C++ and on Windows platform.
Thanks,
|
|
|
|
|
You should gather the requirements of the system and work out the overall design of it first. Then as you take each part and refine its design, you will see where patterns become appropriate for the actual implementation.
Veni, vidi, abiit domum
|
|
|
|
|
manisha.k.chaubey wrote: I need to design a system where-in there is lot of decision making and also system needs to be adaptable as and when required.
Sounds like a human brain. Good luck with that design.
Other than that actually restricting the domain would be the place to start. Additionally focus on what the users want.
|
|
|
|
|
There is no "do-it-all" design pattern. Each pattern is suited for a specific programming task.
What you need to do here is to build a complex Rules Engine that takes in a set of rules (criteria) and emits a set of ordered steps/actions that need to be performed for the specified rules.
|
|
|
|
|
Here's a question I ask myself for a while every time I start a new web project.
I explain
Architecturally all software on which I worked are more or less designed the same way. roughly:
• A database (transactional)
• A data layer (generated from database)
• A business layer (Web Services)
• A GUI layer (Web application)
• And business rules (without rules)
My question is about the business rules. By business rules I mean all rules that design the software given by your business, workflow or technical limitation. (I'm not talking of rules you put in your business only).
In the application on which I worked I found implemented:
• in the transactional database in the form of constraint or trigger,
• in the layer data often generated from the database,
• in the business layer when it comes to more complex business rules,
• In the GUI layer to alert the user as soon as possible and before triggering a request unnecessarily.
I understand the usefulness of business rules in each of these layers of a program. But the technologies that I have used forced us to rewrite or generate business rules in each of these layers because the languages are different:
• In database trigger and constraint are in SQL
• In data layer business rules are in C#
• In business layer business rules are in C#
• In GUI layer business rules are in JavaScript
My question: Is there a language that can accommodate all business rules in a single place or language? Something that prevents me to rewrite several times in different languages my business rules? I know I cannot check all business rules in one place but some yes. for instance the minimum and maximum character of a password can be check in all layer. Right now I write this rule in 3 different languages in 3 different places (Gui/Javascript, Layers/C# and database constraint).
Sub-question: In case of Web Application what if I use JavaScript with nodejs and Mango database?
B413
|
|
|
|
|
B413 wrote: Is there a language that can accommodate all business rules in a single place or language?
No. Even if there were a language that does all[^], there'll still be a difference between validation on the clients' side, and validation on the database-layer.
B413 wrote: My question is about the business rules. By business rules I mean all rules that design the software given by your business, workflow or technical limitation. (I'm not talking of rules you put in your business only).
Your question seems to apply to the database-validation, and all derived checks. BR should be constrained to it's layer.
B413 wrote: Right now I write this rule in 3 different languages in 3 different places (Gui/Javascript, Layers/C# and database constraint).
The stringlength-constraint is an easy one; the datalayer in C# could be generated based on the database-schema, and the GUI could use the StringLengthAttribute[^] information to do it's check - that'd mean that there'd be three languages performing the same check in three different places, but with the declaration only in a single place (in this example, the database). There's an abundance of variations on the above.
B413 wrote: • A database (transactional)
• A data layer (generated from database)
• A business layer (Web Services)
• A GUI layer (Web application)
• And business rules(without rules)
That doesn't mean that they're all built that way. A few years ago we considered the database the DAL. It abstracted away a file-system, made data-validation easy, and gave us a uniform way of accessing the data we store. I've also seen quite some code where the BL is a DLL containing classes derived from POCO-classes based on the DB-schema.
If you want a "single language", you'd be looking at the languages that the most restricted environments (in your collection of environments to support) have in common. Database-servers only speak SQL, and browsers usually only JavaScript - but that doesn't mean that they all need a separate implementation. There are some code-generation-tools out there that can do the boring stuff.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: that'd mean that there'd be three languages performing the same check in three different places, but with the declaration only in a single place (in this example, the database).
The declaration only in a single place because you assume that the code is generated from the database. You generate entities with attributes. But what if
1. You are not working with a SQL server
2. You have business rules you cannot implement in your database
3. You are not working with ASP.NET MVC or WPF
My point of view is that all business rules must be with my model, my entities. partial classes, inheritance, separate check classes, I don't know. What happens in my database is not my problem. As C# developer I don't want to know if my DBA has created constraint or not. I call my check from my GUI. I don't want to write them or generate (writing or generating is the same) them twice. I can do that when I write my GUI with C# classic form. I cannot do that with HTML or ASP.NET MVC.
|
|
|
|
|
I agree with you except that
1. Generating tools to generate from database to business is bad. You give to much power to your database and you repeat the mistakes. I know many developers do that so I expect to argue on this point.
2. As developer a database is just a way to persist my data. It's not my job to create constraint or triggers. (for performance reason I'll perhaps create indexes but that all)
3. It seems increasingly clear that all my BR are a part of the business layer or the entities. If my GUI use the same language than my business layer I can reuse my BR and entities for validation in my GUI.
I still don't understand developers that use HTML/JavaScript as GUI with C# as business layer (web service) because cannot reuse their C# code in their HTML/JavaScript GUI. They don't respect the Don't Repeat Yourself rule.
|
|
|
|
|
B413 wrote: I understand the usefulness of business rules in each of these layers of a program. But the technologies that I have used forced us to rewrite or generate business rules in each of these layers because the languages are different:
If you have the same set of business rules in all the layers then something is suspect.
But other than that you already mentioned code generation so why not just do that for the common functionality.
B413 wrote: Is there a language that can accommodate all business rules in a single place or language
Attempting to generate all rules ends up being a mess because the exceptions add so much complexity that maintaining the generation itself becomes very difficult. Generating the easy stuff is easy and removes much of the rote work.
If you fail to properly design the different layers to support insertion of generated rules then that will also become a mess.
|
|
|
|
|
I can now confirm it's possible to choose C# to build a Winform application and reuse entities and business rules code from business layer to data and UI layers. I can also confirm this is possible with the solution (mongoDB, Node, JavaScript)
|
|
|
|
|
A want to build simple chat application.
After some research on the internet I found that there is already many messaging protocols such as XMPP, STOMP etc. as well as open source messaging servers which implement these protocols.
But how can I use this servers if I need to add some logic to my app. For example the user's ability to send message depend on his state.
I though about another controlling server which will be receive an user state and according to that state will change the state of the messaging server. But I'm not sure that this is the best approach to my problem....
I need your advice and suggestions about the architecture and techniques that will help me to build this app.
Thank you
|
|
|
|
|
This is a very arcane question, but I'm going to ask it anyway: Is there a performance hit by having a method in a separate assembly?
I am designing a website with custom providers. Passwords will be hashed, which means my hashing routine will be used A LOT. Ideal design would be to put the method in the utility assembly, where it could be accessed by both the MembershipUser and MembershipProvider modules. Would giving these modules their own copy of the method noticeably improve performance, or would the nuisance of having two methods that must remain identical outweigh any improvement?
|
|
|
|
|
Strictly from a performance point of view, one assembly is always better than several assemblies.
Each assembly loading has a fixed overhead. For multiple assemblies, you pay the overhead several times.
The overhead of assembly loading at minimum includes the following:
1. Finding the assembly.
2. Loader in memory data structure tracking this assembly.
3. Assembly initialization.
Possibly could be a problem of cold start.
From a design point of view, duplicate code is a bad choice.
|
|
|
|
|
Gregory.Gadow wrote: Passwords will be hashed, which means my hashing routine will be used A LOT.
I sort of doubt that. Only way that would occur is if you required the password on every single request (not session.)
Not to mention of course that this would suggest that you think that the time for this process is at least significant if not the biggest factor in the request.
And regardless the impact of the call itself is going to be trivial compared to the cost of actually doing the hash.
Gregory.Gadow wrote: Is there a performance hit by having a method in a separate assembly?
If you have profiled your application using real message process flows and determined that calling semantics themselves are significant then you probably want to write everything in C++ and create one massively statically linked application.
Myself I doubt that you can measure the normal calling semantics in any application that isn't anything other than a benchmark in all of the major languages. And it won't be significant.
There are of course ways to produce non-normal calling semantics for instance if you dynamically loaded a module for every single method call (unloading it each time) then I would expect that to be measurable. And very, very likely to be a bad design as well.
|
|
|
|
|
This is more of a paranoid situation of having to decide between performance and maintainability. Been there, done that 
Gregory.Gadow wrote: Is there a performance hit by having a method in a separate assembly?
Obviously, there is. But it would be only when the Assembly is loaded for the first time. And if accessing another class has already loaded the said assembly, then you do not even have to worry about it. If you carefully set the Base DLL address of each of your assemblies in the order they're likely to load and the size of the assemblies, you can actually slightly increase the load time (although this will most probably be unnoticeable)
Gregory.Gadow wrote: would the nuisance of having two methods that must remain identical outweigh any improvement?
Remember DRY. Having multiple copies of code actually results in a lot of maintenance headache that does not justify the performance improvement, if any.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
