I've been programming in Delphi with Midas/DataSnap for quite long time and quite happy with it. Moving to .NET I'm more than happy with the ADO.NET DataSet. For CRUD application, I'm highly uncomfortable with any kind of ORM. Generic data-structure with automatic diff/delta handling get my job done better for me, an average database application developer.
Tried to study Java years ago, and could not find similar idea implemented. The closest I could find is SDO (Service Data Object). I thought it should be widely adopted when I saw it, but I'm wrong. Even the spec is rather old now, I still hardly find many people discuss on it or use it extensively. Assuming from information I can find on the internet, SDO usage is highly passive.
Wondering if it's dying ? Any experience in SDO you want to share ? Manual DTO coding is always better ?
Ok. I see. The answer is "no"
;)
Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.
I wouldn't recommend using SDO unless it's imposed on you by some other part of the project.
WebSphere process server uses SDO. It's not really a bad API once you learn it. But the spec and the documentation are vague. It doesn't spell out what happens if you ask for a field that doesn't exist, or whether it does type conversions while getting or setting fields, to name two gripes.
I don't think the API defines how to define new types, so that part will be implementation-specific. Type definitions are based on XSD, so you'll be working with those and all of the associated standards.
As others have implied, the API isn't widely used. This means it'll be hard to find people experienced with it, or help using it.
Related
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.
What exactly is dynamic data? I saw the term in the ASP.NET Overview on msdn. Is it something that we use all the time thats not really mentioned when working with data?
I've built a few web applications already and never came across this term. Is it something that should be used or maybe considered?
UPDATE: I guess I'm not really sure what it's for. I've never had a problem doing LINQ to SQL or Entity Framework before. What makes using Dynamic Data worth it? Is it simply a pattern?
Dynamic Data was a new project type in VS 2008. It used scaffolding & templates to help code faster.
Two big reasons I saw for its usage:
Stand up an admin back-end really
quickly where doing much on the way
of modifying the front-end may not be
needed.
Quickly stand up CRUD apps that are
simple.
Now, it can be modified very heavily. Check out these links for some work others have done on this.
http://aspnet.codeplex.com/Wiki/View.aspx?title=Dynamic%20Data
Matt Berseth - http://mattberseth.com/blog/dynamic_data/
Stephen Naughton - http://csharpbits.notaclue.net/
http://weblogs.asp.net/craigshoemaker/archive/tags/Dynamic+Data/default.aspx
http://blogs.msdn.com/rickandy/archive/2009/01/08/dynamic-data-faq.aspx
Fast Forward to Today:
As MVC has matured they have introduced many of the ideas that were in Dynamic Data. Scaffolding, templates, etc... to help one quickly get up and running BUT also have the ability to modify more easily and is designed for many other desirable features.
Where does Dynamic Data fit today, especially with Light Switch thrown into the mix? Great question and my only answer at this point is it still fits for the two items originally mentioned but with the advent of MVC having these abilities WITH added capabilities and Light Switch it's going to see minimal usage.
The page you linked to has a link to the ASP.NET Dynamic Data Overview. Is there something on that page you would like explained?
Dynamic Data is a way to have your CRUD data logic written for you automatically using the Database Schema.
Take a look at this walkthrough to give you a quick jist.
It isn't something I use, but I can see where it has merit in a really rapid development scenario. I don't know if it will stand the test of time or prove useful or maintainable.
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/
For various common reasons I wanted to use tracing for my ASP.NET application. Especially since I found out about the possibility to use the Service Trace Viewer tool which allows you to examine your traces in a powerful way.
Since I had never used this trace thing before, I started stuying it. After a while of Google, SO and MSDN I finally have a good idea of how things work. But I also found one very distrubing thing.
When using trace in ASP.NET applications it makes a lot of sense to group the trace messages together by web requests. Especially since one of the reasons I want to use it is for studying performance problems. The above mentioned tool also supports this by using <Corrleation> tags in the generated XML files. Which in turn come from System.Diagnostics.Trace.CorrelationManager. It also allows other nice features like Activity starting/stopping, which provides an even better grouping of trace messages. Cool, right?
I though so too, until I started inspecting where the CorrelationManager actually lived. After all - it was a static property. After some playing around with Reflector I found out something horrifying - it's stored in CallContext! Which is the kind of thing we shouldn't be using in ASP.NET, right?
So... am I missing something here? Is tracing really fundamentally flawed in ASP.NET?
Added: Emm, I'm kinda on the verge of rewriting this stuff myself. I still want to use the neat tool for exploring the traces. Any reason I shouldn't do this? Perhaps there is something better yet? It would be really nice if I got some answers soon. :)
Added 2: A colleague of mine confirmed that this is not just a theoretical issue. He has observed this in the system he's working on. So it's settled. I'm going to build a new little system that does things just the way I want it to. :)
Added 3: Wow, cool... the guys at Microsoft couldn't find anything wrong with using Correlation Manager in ASP.NET. So apparently we're not getting a fix for this bug after all...
You raise a very interesting question. After looking at Reflector, I also see that CorrelationManager is using the CallContext to store the activity id. I have not worked with tracing much, so I can't really speak on behalf of what types of activities it tracks, but if it tracks a single activity across the entire life cycle of a page request, per the article you referenced above, there is a possibility that the activity id could become disassociated with the actual activity. This activity would appear to die halfway through.
HttpContext would seem ideal for tracking an entire page request from beginning to finish, since it will be carried over even if the execution changes to a different thread. However, the HttpContext will not be transferred to your business objects, where as the CallContext would. On a side note, I saw that CallContext can also be transferred when using remoting between client and server apps which is pretty nifty, but in the case of tracking the website, this would not really be all that useful.
If you haven't already, check out this guy's site. The issue described in this article isn't specifically the same issue that Cup(Of T) article mentioned, but it's still pretty interesting. He also provides several very informative links on the page that describe components of the CorrelateionManager.
Unfortunately, I don't really have an answer to your question, but I definitely find the topic interesting and will continue looking into it. So please update this post as you learn more. I'm curious to see what you or others (hopefully someone out there can shed some light on the topic) find while looking into this.
Anyway, good luck. I'll talk to some of the peeps at my work about this and post more later if I find anything.
Chris
OK, so this is how it ended.
My colleague called Microsoft and reported this bug to them. Being certified partners means we get access to some more prioritized fixing queue or something... don't know that stuff. Anyway, they're working on it. Hopefully we'll see a patch soon. :)
In the mean time I've created my own little tracing class. It doesn't support all the bells and whistles that the default trace framework does, but it's just what I need. :) More specifically:
It writes to the same XML format as the default XmlWriterTraceListener so I can use the tool to analyze the logs.
It has a built in log rotation - something my colleague had to do himself on top of XmlWriterTraceListener.
The actual logging is deferred to another thread so performance can be measured more accurately.
Correlations are now stored in HttpContext.Items so ASP.NET threading peculiarities don't affect it.
Happy end, I hope. :)
As someone who has spent around 10 years programming web applications with Adobe's ColdFusion, I have decided to add ASP.NET as a string to my bow.
For someone who has spent so long with CF and the underlying Java, ASP.NET seems a little alien to me. How should I go about getting up to speed with ASP.NET so that I can be truly dangerous with it? Do I need to know C# at any great amount of detail?
I want to be in a position where I can build basic web apps fairly quickly so I can learn more doing the tricky stuff.
I'm only maybe six months down the same path, but here are some thoughts from my experience so far:
The C# language shouldn't give you much problem if you have very much experience with Java at all (or even CFScript). As a reference, though, when I was starting, I found csharp-station a good primer for language basics. It won't help you much as far as the ASP.NET side goes; but it is good for syntax. More you'll be familiarizing yourself with the .NET libraries. The IDE actually can be an enormous help here.
Here are the three biggest differences I found making the transition:
ASP.NET Server Controls - In ColdFusion, you really have pretty
direct control over the HTML; you
work very closely with the page.
This isn't so much the case in
ASP.NET. The server controls are
meant to relieve you of a lot of the
tedium, but at a cost of maybe some
direct control. As a CF programmer,
I'm very particular about what gets
actually output to the browser; and
at first ASP.NET frustrated me
because it spits out a lot of extra
code. Still, the controls are
really powerful, and it pays to
familiarize yourself with them.
Form and validation controls,
especially, save you from a lot of
the tedium in CF of handling post
back and validation. W3Schools
actually has a decent list of web
server controls.
The page model - ColdFusion is pretty agnostic in terms of page
flow. ASP.NET is very much geared
towards using post backs, and is
very event driven. If you're not
using a framework with CF (e.g.
Model Glue), this may be foreign to
you. .NET takes care of handling a
lot of the post back behavior for
you. Also, not to say that
ColdFusion can't be object and
function driven by good use of
CFC's, but ASP.NET really tries to
push you down the OO path compared
to CF in my experience.
Database access - Using ASP.NET really made me appreciate how
powerful cfquery really is. The
csharp-station site also has a good
tutorial on working with the native
.NET db tools. I haven't worked on
enough projects yet to start looking
around for DB access extensions; I'm
pretty sure Jeff recommended
something that they used for
building this site, so you might
check that out. Otherwise, I really
suggest you familiarize yourself
with the DataSet object. It's
somewhat similar to a query object
in CF, and lets you run query of
queries, etc... Looping over
queries in CF is very common, but it
doesn't happen nearly as much in
ASP.NET because of data binding.
Microsoft has a video called ASP.NET for ColdFusion developers you may be interested in.
Edit, here's another
ADO.NET is a core concept, and I would really recommend taking a course in it. Having a qualified instructor explain exactly what the differences are between a DataSet, DataReader (and so forth -- there are a lot of different data access object types) is invaluable. Not to mention you'll better understand the appropriate time and place to use each; and you can ask questions and get immediate answers in a classroom setting.
I took an ADO.NET class (one night a week, about 8 weeks) at my local university for around $400. Even if my company hadn't paid for it, I would have been happy to, and I can highly recommend anyone trying to learn .NET do the same.