I've been trying to write an open-source profile provider to work against PostgreSQL (I was frustrated with the limitations and incompleteness in the other projects I'd seen available), but the documentation and examples of how people use it was surprisingly sparse. Even the SO tag for asp.net-profiles has a little over 100 questions associated.
The more I dig in to making it work, the less and less practical it seems; the value added does not seem to justify the complications associated; additionally, it only seems to work on a limited scope of web projects without a bunch of extra work.
I feel like I'm being led to the conclusion that it is not a popular technology, and that there are better ways to persist a more robust user-based information set.
Is my take on this fundamentally flawed? Is this widely used? I'm on the cusp of abandoning my profile provider as it seems to offer little of value.
I have always eschewed the ASP .NET Membership provider in favor of a custom implementation of IPrincipal for one simple reason. I've almost never needed the out-of-the-box functionality it provides.
Any custom implementation means creating your own implementation of MembershipProvider. Amongst other methods that I have never implemented, it includes wonders like RequiresQuestionAndAnswer and MaxInvalidPasswordAttempts. It forces an implementation upon you that you might not need and will take you more time to complete properly.
Sure, you could cheat and put a NotImplementedException in methods that you're not particularly bothered about, but what right-minded coder would feel comfortable with that in a production system? :D
I really like a lot of Microsoft's stuff, but my experience is that a lot of their "out-of-the-box" solutions are fine in vanilla mode, but the wheels tend to come off when you travel off the beaten path. A bit of cherry-picking is therefore required. My advice? Leave this one on the vine.
No, the Profile system in asp.net is not widely used, primarily because of the reasons you mention. It's just not useful for a lot of people.
The easiest solution is to simply create a profile table in your app, then key it on the ProviderUserkey of the Membership system.
Related
At this point in the development of our web application we are slowly finding the needs of the application to differ from what the membership provider offers by default. As we implement new features we are overloading the default methods and changing a lot of things to the point that it's getting confusing and the point of inheriting the MembershipProvider does not seem necessarry any longer.
My question is: besides the use of the custom controls like Login, CreateUserWizard (which we are already not using), RecoverPassword, etc. what is the benefit of using the MembershipProvider? I have already looked into such things as encrypting password and I feel that the Crypto helper class will provide that to us. What other things should I be aware of?
I cannot enumerate a list of things to be aware of off the top of my head, but I would encourage you to get rid of the MembershipProvider as soon as possible anyway. Don't invest any more time in bending it to suit your needs.
The MembershipProvider's architecture doesn't scale to the complexity of real-world applications and it is only really suited for 30 minute on-stage demonstrations.
Let's say we are developing an E-Commerce Web application for a small to medium sized business. Let's further assume that the business is likely to scale over time. In other words, the product line will typically grow.
Up to now I have developed n-tier solutions using ADO.NET and stored procedures with the help of the SqlHelper class. For bigger applications I have used Enterprise Library (2.0).
I would like to move towards an ORM-based approach and am starting to learn LINQ as well as making the switch from ASP.NET Web Forms to ASP.NET MVC. I do not want to go with LINQ-to-SQL. The question is not whether an ORM is required but if the Entity Framework ORM is overkill for such a project. I don't mind a learning curve if it is warranted for the task in hand.
As regards "overkill", I would like to know if:
EF is faster than someone with the correct skills coding queries manually
EF leads to unnecessary code bloat
EF unnecessarily shields devs from code-level details of their queries
LINQ-to-Entities is suited for projects of this size
In fact, if anyone thinks that an ORM is overkill for such project I'd like to hear reasons why.
EF is not overkill for web apps.
I disagree with a lot of what is stated in your referenced article. I do agree devs should have decent skills with SQL BUT ORMS do a great job in getting a devs job done more quickly.
Speed of ORMS - They are getting
better all the time & they allow you
to call SP's or modify the queries to
get max speed when necessary. There are also great profilers out there for monitoring ORM performance like EFProf.
Slows down the coding process -
Really!!! Once learned it speeds it
up.
Devs needing to know SQL - I agree.
However, ORMS especially with LINQ
syntax often allow devs to write more
complex SQL than they would have on
their own.
Devs write efficient queries already - REALLLYYYY!!!! Just ask the DBA his/her thoughts! I happen to think I do but so does everyone else. See the problem. :-)
Code Bloat - Have to disagree, especially with ones that have LINQ.... It often makes the code more readable and reduces the line count often.
Forget about LINQ - This ship has
sailed. LINQ Rocks!!!! Go with it or
be left behind. It's not just used in ORMS. It can be used against, arrays, objects, XML, files, twitter and the list goes on and on.... Get to know LINQ.
The article talks about some of the inspiration of the latest developments out of MS as coming from Ruby on Rails. ROR has an ORM based on Active Record in it.....
ORMS are good. They don't have to be used everywhere and everytime but they are good and should be considered.
Although this is a general answer be wary of any opinion which has these comments in:
"X tool stinks, I write in Y tool and I can do it faster than in X tool."
Or course a Latin speaker speaks better in Latin.
EF has a learning curve, but anything new does. EF is not overkill, but as per any system being written use the right technology for the right project.
Looking at the article, the first thing I would see and disagree with is this:
I strongly believe that modern web
developers should:
•Love databases.
•Write highly efficient queries.
•Minimize code.
•Design self-evident user interfaces.
•Work quickly.
I am not sure how many people view web development, but in my mind a web devloper should focus on functionality and business rules. The pure database and SQL code should never be done by someone on my team that would be more productive writing business functional code.
This is where Entity Framework comes into play. It is considered a Rapid Application Development tool (as are most other ORMs). These tools are built specifically to allow you to focus more on how to fulfill the user requirements and less on what the right way to write a query is.
With that being said, I would also say that using the tool naively could be dangerous. When you use Entity Framework you still have to be cognizant of the implications of using the object graph that you are requesting.
It is by far not overkill, the tool is very simple to use and simple to learn. I would argue that it is easier to "fix" an Entity Framework rather than fixing a raw SQL Query and ADO transaction set.
On smaller projects my base recommendation is almost always go with some type of ORM. On enterprise applications you have to be a bit more careful and it entirely depends on budget :-).
An ORM can be quite useful, if used properly and you understand what it's doing for you. You should definitely use one, if you already have some understanding of database design and querying.
The point of the article, primarily, is that the concept of not having to learn anything about database design and querying somehow makes your life better is a fallacy. I prefer very thin layers of abstraction between code and database - I feel that lets me focus more on good user experience.
I personally feel the press behind EF is encouraging new coders to ignore some necessary basics. I've worked with some of them, and think they were done a disservice.
Of course, there are those that will very strongly disagree. No problem!
I know developers who started off loving it, and now don't. But I also know developers that love EF and swear by it.
I've used EF, LINQ to SQL and NHibernate and others over the years.
Best advice: give it a try. Come to your own conclusion.
(Disclosure: I'm the writer of the article you cited).
Definetely not an overkill. Go ahead and use EF.
It actually depends on the complexity of your data model rather than the type of application it is.
If you have a relatively simple data model, then EF may be overkill (if you don't know it yet). Linq-to-SQL may be a better choice (less learning curve, though it also has limitations such as no many-to-many mappings).
If your data model is more normalized, rather than just table based then EF will definitely pay off in the long run, or nHibernate, or any other more advanced ORM.
The article you link to seems to indicate that ORMs in general are bad, not just EF. When confronted on his points, he seems to back off them to some degree. It seems like he is trying to justify a blanket concept (that new developers should have to learn low level coding, particularly SQL, before going to high level frameworks) by inventing questionable points.
I'm planning to set up an online store for a friend, unfortunately his product line introduces some demands most out-of-the-box solutions don't fit. I'm hoping somebody here has had some experiences with an open source package that they can recommend.
The specific issue is that the products are going to number in the hundreds of thousands. Since the type of products have a lot of clearly defined specifics, searching and sorting can be (and needs to be) very granular and efficient. For this reason, the primary requirement is that I replace the product and search-related parts of the app, but only those parts. I'm hoping that there's an ecommerce solution with the product segment abstracted so that I can change the database tables, product display code, search code, and create the obvious code to interact with the database.
I'd prefer something that's built on ASP.Net MVC since it'll play nicely with some extensions I am considering for the future but I'd consider WebForms. I'd also like it to be something that functions on GoDaddy's Hosting, though I'm not optimistic, I just got the account before I discovered how terrible of an ASP.Net web host they are. And finally I need something that's reasonably mature as I don't have time up front to deal with a system that hasn't been tested, and the majority of issues worked through already.
I'd appreciate any ideas.
Edit: I've done a bit of searching already and I've found several (at least 8) MVC projects, but I haven't had time to examine them properly for the needs listed above. I also can't be sure which ones have matured from real world application...So I'm mostly looking for advice either based on a familiarity with using the app or at least reading enough about it that you would feel it's good to recommend.
Thanks Everybody!
Check out http://code.google.com/p/sutekishop/
Check out http://thebeerhouse.codeplex.com/
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How effective is obfuscation?
Protect ASP.NET Source code
(Why) should I use obfuscation?
Is obfuscation the best answer for protecting our code ?
*Specially in Web Projects when you want to deliver your web projects as libraries of code to your customer ( the person who ordered ) *
Edited
At first my priority is Server-Side Code
and second Client-Side
but the main goal is when you want to deliver a complete web project
and you made every piece of your code as components and dlls now how effective can you protect them and doesn't allow others to make your code back from them .
Edited
The problem is that I want to protect the code that I'm written to a company that they ordered , now all my code are inside some DLLs ,
Now they can reverse engineer that and get my code , I want to prevent them from doing so ,
Is there anyway to do so or not ?
I think that is a unique question , And I didn't ask for what obfuscation is nor for tools of doing this activity , further than that I think this is apart from Client-Server Security
Sorry if my question wasn't clear at first , but if that is really a case to be deleted , no problem for me
Also
Also I wanted to have a comparison look at this problem and the solutions ,
because I think obfuscation wasn't the only possible solution at this , I think we can have maybe some logical sort of workarounds about this problem
Maybe not the best. If you are really ambitious, you can write your own web server (plugin).
But is it worth the effort?
Software is similar to a bike in the Netherlands, there is no known way of protection that is 100% safe. You use either a better protection than the other bikes (thieves are lazy). Or you must obfuscate the bike so they won't take it.
Another way to increase the level of protection is to use custom made ActiveX code to store mission critical algorithms. Of course, they can be reverse engineered, but javascript is easier.
What exactly are you trying to protect your code from?
Does your client-side code contain valuable business logic?
If not: you shouldn't bother obfuscating something that doesn't have much value. Personally I think clientside code theft is a something that people are far too concerned about. 99% of web apps don't really have anything special in terms of implementation on the client side. What you need to worry about more is someone ripping off the idea or visual look, which you obviously can't obfuscate.
If it does: you need to consider refactoring that logic out of the client side, as even with heavy obfuscation, a determined party will always be able to untangle it relatively easily. The code that adds real value to your app should ideally be running on your servers where it's considerably more difficult to get access to.
Even if people stealing your html markup or javascript was a something to worry about (and it probably isn't), obfuscation doesn't really solve the problem. In my opinion it is a waste of effort and money.
Hosting a critical function as a web service is probably the most sure way to protect it. It keeps the code out of the user's hands entirely. But then you're stuck hosting a service, and your users have to be on line to use your functionality.
Obfuscators help by hiding useful names and replacing control flow with weird but logically equivalent alternatives. They might thwart an amateur, but they'll only slow down a skilled reverse engineer for a few minutes, and they won't stop someone who is determined to penetrate your secrets.
I you really want to protect your code, you should write native code using a native code compiler (C++, Delphi). This still does not guarantee that your code is 100% safe because any experience developer can read assembler and essentially disassemble the native code program.
A determined hacker will always find a way to get to what they want.
The best we can do is to make it hard or painful for the would-be hacker to get at our code and the following options can help us:
Customize the CLR engine
Run an obfuscation tool over your code and use name and control flow obfuscation and string encryption
Make the application a Web-based application where all your proprietary code sits on a server somewhere
Watermark your code using your own custom techniques to "throw off" the would-be hacker
Implement techniques to prevent debugging (this is a very advanced topic!)
I really like a comment made by one of the head developers of the .NET framework where he said that he does not feel it's really the fact that others can get at our code that should be a concern to us, but rather, we should concern ourselves with the level of support we provide with our products.
So if we provide a good support base, it does not matter what the hackers do with our code, because the clients will trust us and our ability to support them using our product and not some cheap hacker-hacked program.
NO, obfuscation is not the best way to protect your code.
The tool you need to use is "copyright".
There is no (technological) way you can protect you code from someone determined enough (provided they have access to the binaries / scripts).
What you can do is prevent them from legally modifying/distributing your code.
The normal server-side code in Web projects should under no circumstances be visible to the outside world. So there is no point in obfuscating the code.
Besides that two minior points:
Javascript code is visible to the user and can be obfuscated. Minimizing javascript to save bandwidth is recommended anyway. Minimizing js also obfuscates the code.
Also important is that on production system the configuration setting customErrors should be set to RemoteOnly or On to avoid showing a stacktrace with to much code details.
If your client side code has any broad value to others, it will get reverse engineered regardless of any obfuscation.
The reality is that it's likely not going to be broadly useful to many and there is a lot of other code out there to look at so probably not worth doing more than minifying the code which is plenty of obfuscation and if your code is large, it will improve download speed.
Have you considered the alternative? That it's a good thing to give somethings back to the community? I'm sure you've looked at the code of more than one site, no?
I was using a CASE called MAGIC for a system I'm developing, I've never used this kind of tool before and at first sight I liked, a month later I had a lot of the application generated, I felt very productive and ... I would say ... satisfied.
In some way a felt uncomfortable, cause, there is no code and everything I was used to, but in the other hand I could speed up my developing. The fact is that eventually I returned to use C# because I find it more flexible to develop, I can make unit testing, use CVS, I have access to more resources and basically I had "all the control". I felt that this tool didn't give me confidence and I thought that later in the project I could not manage it due to its forced established rules of development. And also a lot of things like sending emails, using my own controls, and other things had their complication, it seemed that at some point it was not going to be as easy as initially I thought and as initially the product claims. This reminds me a very nice article called "No Silver Bullet".
This CASE had its advantages but on the other hand it doesn't have resources you can consult and actually the license and certification are very expensive. For me another dissapointing thing is that because of its simplistic approach for development I felt scared on first hand cause of my unexperience on these kind of tools and second cause I thought that if I continued using it maybe it would have turned to be a complex monster that I could not manage later in the project.
I think it's good to use these kind of solutions to speed up things but I wonder, why aren't these programs as popular as VS.Net, J2EE, Ruby, Python, etc. if they claim to enhance productivity better than the tools I've pointed?
We use a CASE tool at my current company for code generation and we are trying to move away from it.
The benefits that it brings - a graphical representation of the code making components 'easier' to pick up for new developers - are outweighed by the disadvantges in my opinion.
Those main disadvantages are:
We cannot do automatic merges, making it close to impossible for parallel development on one component.
Developers get dependant on the tool and 'forget' how to handcode.
Just a couple questions for you:
How much productivity do you gain compared to the control that you use?
How testable and reliant is the code you create?
How well can you implement a new pattern into your design?
I can't imagine that there is a CASE out there that I could write a test first and then use a CASE to generate the code I need. I'd rather stick to resharper which can easily do my mundane tasks and retain full control of my code.
The project I'm on originally went w/ the Oracle Development Suite to put together a web application.
Over time (5+ years), customer requirements became more complex than originally anticipated, and the screens were not easily maintainable. So, the team informally decided to start doing custom (hand coded) screens in web PL/SQL, instead of generating them using the Oracle Development Suite CASE tools (Oracle Designer).
The Oracle Report Builder component of the Development Suite is still being used by the team, as it seems to "get the job done" in a timely fashion. In general, the developers using the Report Builder tool are not very comfortable coding.
In this case, it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background.
Unfortunaly the Magic tool doesn't generates code and also it can't implement a design pattern. I don't have control over the code cause as i stated before it doesn't have code to modify. Te bottom line is that it can speed up productivity in some way but it has the impossibility to user CVS, patterns also and I can't control all the details.
I agree with gary when he says "it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background" but also I can't agree more with Klelky;
Those main disadvantages are:
1. We cannot do automatic merges, making it close to impossible for parallel development on one component.
2.Developers get dependant on the tool and 'forget' how to handcode.
Thanks