When we are creating separate classes means (tiers) will take more time to traverse between pages.Whether this is the case?
I know there is many advantages for using the tiered architecture.Like easy to maintain,easy to understand.
What is actual scenario ?
To answer your question, class will take performance hit as they will be destroyed by GC which in itself is a heavy operation.
Architecture is something which helps you achieve the business requirements with maximum capacity to scale. Now adding a tier in your application would definitely bring in a class, the object of which will be created and again after use, it will be destroyed by garbage collector. So there is a very thin line on what to use. You have to decide it according to your business and scalability.
Creating and destroying classes takes time, but in an OO language this is unavoidable.
As far as .NET is concerned it makes no difference, performance wise whether these classes are in the code behind files of ASP pages or in a separate library.
Related
I'm building a mobile app that have many panels and I was wondering if it's a good idea (in regards of performance, memory use, code size and ease of maintainability) to have one Ractive instance by panel or if it's preferable to have only one Ractive instance for the whole application? I'm leaning towards many instances for ease of maintainability but I really don't know how it will affect performance and memory use.
The overhead for creating additional instances is very small - it's only really if you're creating hundreds or thousands of instances (whether directly, or as inline components) that you might find you need to optimise things.
So in general I'd advise writing the application in the way that's most maintainable. If you did find that performance was a problem, then depending on the nature of your app you might find a happy medium between having a single instance for the entire thing, and dividing it too finely.
I'm in the middle of creating a fairly large flex application, and over time, it's started to edge toward unmaintainability.
I'm using 3 external library projects which are still small enough to remain maintainable and reusable, but the main project seems to be impossible to keep organized.
Part of the problem seems to be that I have about 30 objects inheriting from a single abstract superclass type object. All of child objects have both a logic component and a ui component which are tightly integrated to each other. The superclass object has about 60 shared methods and properties, most of which can be overridden in any of the child classes, a few of which should be overridden in all child classes.
To add to the complexity, these have to communicate between themselves, and this is usually via the container object they reside in. Additionally, the main project has to create value objects out of these so they can be sent to a FlourineFX backend for storage, and additional authentication/authorization logic.
I've created much larger projects in languages from old MS BASIC (pre VB), Ada, VB (3 to .Net 1), C++, and C# without this problem. (well, old VB tended toward this problem because of the same tight integration between UI and logic) So, is there any thing I'm missing, or is there any best practices that I can implement? (even if that means rewriting entire swaths of code)
And yes, this may be an extension to this conversation.
Do you use any framework implementations in this project? A framework would help modularise a lot of this complexity and hopefully remove a lot of the dependencies you seem to have between the application logic and views.
I'm a massive advocate of the RobotLegs framework which implements the mvcs pattern and offers dependency injection for use throughout your project. There are others out there such as pureMvc, Cairngorm, Mate. Have a look around and see which best suits your project.
It sounds to me like you really need to do a big refactor which is a risky process in such a large project. It could be well worth it if you're struggling to maintain it. If you are going to refactor definitely refactor into a framework. It's probably the area that will give you most bang for your buck (pound for the brits ;) )
James Hay's conversation starter is a good one, but for HUGE applications I would take time to test and consider memory management for some of the suggestions in that answer/conversation. RobotLegs is great and all, but I would worry about 'over-singletonization' and potential memory management issues that it would create (though I have to admit that I've never used and avoided robotLegs because of it's use of singletons).
If you were thinking IoC and dependency injection (like that which robotLegs provides), I'd suggest a look at swiz -- I really like the new 'instance-direction' swiz has taken. My only issue with it (in the current beta) is they have some cleanup issues, though these issues are easy enough to remedy (look through their source and any time you completely remove a component from the stage you'll have to play the profiling game and make sure everything is getting cleaned up --- we had to create temp functions to remove the changewatchers and destroy 'display list bean instances' until they get that stuff fixed).
The project I lead had many of the potential issues you must be worried about. Our ERP app has thousands of modules and the thing is running on client machines for hours/days at a time, constantly loading and unloading modules. Garbage collection and memory management were and is THE issues.
As for using mate, the annoying carhorn, or pureMVC, we created our own framework two years ago. It borrowed ideas from cairngorm, but overall my suggestion is to use whatever you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules) and this has made maintainability and code readability super smooth.
I hope my blabbing has helped at least a bit.
Best of luck.
It seems like you just need a clean separation of UI and domain components. Look into the component guidelines and the Presentation Patterns discussed by Martin Fowler, especially the Presentation Model.
To bring these pieces together, you might want to use an IoC container like Spring ActionScript. This is a non-intrusive framework that allows you to keep layers separated.
Don't let a framework get in your way. I've seen massive misuse of frameworks like PureMVC and Cairngorm mainly because apply them in an all-or-nothing fashion.
I'm creating a game and I create sprites(enemies). I keep creating and destroying sprites. Flash/Flex has a garbage collector which handles the destruction of unused resources. Should I create an object pool to reuse them, or should I leave flash/flex to handle the creation/destruction of objects?
Which option is better from the performance point of view?
Leave it to the Flash player to handle and only worry about optimisation if there turns out to be a performance problem. Its all hypothetical until then anyway.
Object Pooling is an excellent idea if you need to create/destroy lots of items. Flex 4 is doing this with their DataGroup for managing creating destroying itemRenderers while you scroll through huge lists, and it dramatically improves rendering performance.
And all of the particle frameworks HAVE to use this to be competitive.
Check out these Object Pooling Demos and Presentations for Actionscript:
Object Pooling in AS3 by Lost in Actionscript.
Polygonal Labs' ObjectPool class and some examples.
Object Pools prevent "stuttering" example.
Grant Skinner describes some bits about Object Pooling in his Presentation, among other neat things.
I'd recommend using an object pool if you're creating/destroying lots of objects. Performance optimizations are very important early on if you're building a complex project and you won't have time to go back to it for a while. Object Pooling goes a long way and is very easy to implement.
Hope that helps,
Lance
New to .net and was wondering if there is a performance gain to keeping an instance of, for example a DAL object in scope?
Coming from the Coldfusion world I would instanciate a component and store it in the application scope so that every time my code needed to use that component it would not have to be instanciated over and over again effecting performance.
Is there any benefit to doing this in ASP.Net apps?
Unless you are actually experiencing a performance problem, than you need not worry yourself with optimizations like this.
Solve the business problems first, and use good design. As long as you have a decent abstraction layer for your data access code, then you can always implement a caching solution later down the road if it becomes a problem.
Remember that any caching solution increases complexity dramatically.
NO. In the multi-tier world of .asp this would be considered a case of "premature optimization". Once a sites suite of stubs, scripts and programs has scaled up and been running for a few months then you can look at logs and traces to see what might be cached, spawned or rewritten to improve performance. And as the infamous Jeff Atwood says "Most code optimizations for web servers will benifit from money being spent on new and improved hardware rather than tweaking code for hours and hours"
Yes indeed you can and probably should. Oftentimes the storage for this is in the Session; you store data that you want for the user.
If it's a global thing, you may load it in the Application_Start event and place it somewhere, possibly the HttpCache.
And just a note, some people use "Premature Optimisation" to avoid optimising at all; this is nonsense. It is reasonable to cache in this case.
It is very important to do the cost benefit analysis before caching any object, one must consider all the factors like
Performance advantage
Frequency of use
Hardware
Scalability
Maintainability
Time available for delivery (one of the most important factor)
Finally, it is always useful to cache object which are very costly to create or you are using very frequently i.e. Tables's Data (From DB) or xml data
Does the class you are considering this for have state? If not, (and DAL classes often do not have state, or do not need state), then you should make it's methods static, and then you don't need to instantiate it at all. If the only state it holds is a connection string, you can also make that property field a static property field, and avoid the requirement of instantiating it that way.
Otherwise, take a look at the design pattern called Flyweight
I am working on maintaining an ASP.NET website, and I've noticed the business layer and other supporting libraries make heavy use of HttpContext.Current.Session. This makes it hard to keep track of session variables, to determine what they're used for and why they even exist.
Is it considered bad practice to use the session in the business layer? And would it be wise to start moving all code that uses the session into the code-behind?
It's almost never a good idea. There's lots of reasons, but here's a couple:
you'll never be able to use business layer code in anything other than ASP.NET
Unit Testing becomes much more of a pain or even impossible.
We ran into huge headaches with this exact same situation when we started to build services that utilized common business layer code.
I follow this rule - any class in System.Web namespace (javax.servlet package in Java) should not be present in your business layer.
Yes - the BL should not have any knowledge about the Session. Its a dependency that you don't need.
make a class that is an indirection, in which case on the web it may return values from HttpContext.Current.Session, and in other areas would resolve that from somewhere else. IE have an interface ISessionStore and have concrete classes WebSessionStore and WindowsFormsSessionStore, etc.
this will make your code easier to test and also gives you expansion paths when say, you now want x business logic to run in a windows service where it can run x piece of code every y minutes.
In my opinion it is bad practice.
It makes it pretty hard to dissociate that business layer from the environment. If you expect to unit test the thing for example, you're out of luck.
One way to take care of that simply would be to insulate this into an abstraction for now, so that you can pass a "state cache" around and not refer to HttpContext. That will take you at least to some degree of abstraction.
Another more interesting question is, why does the business layer need to refer to that?
its always better to have a centralized Cache/Session manager which encapsulates the complete interaction with session/cache or whatever persistence method you use. having your BL to interact with sessions is definitely a very bad practice and in a way defeats the purpose of the tiered architecture altogether.