I've developed an entire corporate website (including full-scale CMS) using only Web Matrix. I have implemented my DAL as a user control (.ascx) that other pages and controls use (as in ). There are a handful of business object classes that are themselves defined
in this control (like User and Company for instance). So... every page of the site includes UserMan.ascx, which persists some visitor-profile and history information in the Session object, and writes other of the user-specific data directly to the database
via the DAL.ascx. This is done so every single action (page visit, webinar registration, search, etc..) can be recorded. There are various other user controls (registration forms and the search engine for instance) that are in some of the pages and behave
the same way in regards to doing their data I/O via the DAL.ascx control. Among the specific object methods in the DAL control, there are also generic SQLQuery and SQLNonQuery methods that can be used as one-offs. DAL.ascx passes DataSets, DataReaders, or
actual business objects (depending on the methods invoked) back to the calling controls. I took a bit of a design-on-the-fly approach to this, and I'm going to now start optimizing the architecture. The first thing I'm going to do is separate all business
objects from the DAL, so I can make this closer to a 3-tier application (and build up my BLL easier). My big question is, how important is it for me to move away from my user control (.ascx) approach to all compiled dlls? The current method does not require
that I re-compile anything, ever - just deploy. I use Web Matrix, so I don't care about IntelliSense... anybody want to slam my approach (or back it up?)?
It is a very good idea to do this. User controls are not meant to be class libraries. They are meant to replace the include directive of classic ASP so that you could put standard UI pieces on a page in a program controllable fashion. BTW, if you need to record
page visits and other actions that happen on every page you might look at what you can do in the hooks (like BeginRequest/EndRequest BeginSession/EndSession) of the HttpApplication class. Or check out the HttpHandler and HttpModule classes. By using these
methods and classes you can avoid injecting code or user controls on every page. - Eric McVicker
Ahem... yeah I'll slam your approach =). >>I took a bit of a design-on-the-fly approach to this The aforementioned statement, to me at least, means you should consider starting over. You will always pay (regardless of how smart, talented, hard working you are)
in the long run for building apps without planning, designing, prototyping, and modeling. >>implemented my DAL as a user control That's honestly the first time I've ever heard of someone doing that. To your credit, it's a creative way of doing it, but I can
honestly see a host of reasons for why that could be problematic. Firstly, a user control is for creating a UI interface, not Data Access. Secondly, I like to have the capability to re use both business objects and data access objects throughout my enterprise,
regardless of whether a consuming application is going to be a web app, a console app, a windows service, or a winforms application. With this model, you simply can't do that. Thirdly, you should really consider separating your layers out, and now that you've
built your whole application around this single user control for data access, you're putting yourself up sh*t creek, sans paddle. How big is this one ascx page? The code has to be ludicrously volumnous... another telltale sign of poor design. Maintenance will
be (without a doubt) a nightmare, and nightmares are bad =). >>My big question is, how important is it for me to move away from my user control (.ascx) >>approach to all compiled dlls Really important. That's the first step you should take... and I would start
right now! >>I use Web Matrix, so I don't care about IntelliSense Your loss =) Hope this helps, -A
The ascx is not that large at all thanks to the generic one-off methods. The business objects are simplistic and don't take up many lines (I am going to separate them though). I am definitely not starting over. It is not going to be difficult at all to move
to a compiled and layered framework (if someone can convince me I must) since I have this wonderful content management system. All I'd have to do is modify 10 or so template aspx files, and have the CMS re-write all the 300+ site pages for me in a matter of
minutes. So I may be up sh*t creek in your eyes but I have a huge a** paddle and a nuclear powered steam engine as a backup. This system is live (beta), and works well. Maintenance is extremely easy, as is deployment. Enterprise re-use is a non-issue since
every object lives and dies only on the website, which is hosted. If we do ever want to port objects or data over to another corporate app, a simple web service would do the trick. >>a user control is for creating a UI interface, not Data Access I proved it
can be used either way. The compiled and running application on the server is going to be the same in terms of the Intermediate Language that is created whether I include the code with an import statement from an assembly or through the non-pre-compiled code
of a user control. In my situation the user control approach is doing fine, and no one has told me yet what performance gains I can expect by going to the pre-compiled structure... just that I should do it because everyone else does it.
>> and have the CMS re-write all the 300+ site pages for me in a matter of minutes That's fine. I don't know what solution you're developing, so whatever you want to do is your business, I'm just trying to help you. >>I proved it can be used either way Sure,
you can do a lot of things a lot of different ways, but it doesn't mean it's going to be flexible, re-usable, or correct. Try convincing anyone worth their salt that it makes sense to use a user control for your data access layer. A user control, just to reiterate,
is meant to develop user interaces, a completely different layer from data access. Look at any architecture diagram, at the very least you should have: UI, BLL, DAL. You're mixing an abstract class that's meant to be used for UI, and using it for your data
layer. A more refined approach is: UI, UI Process, BLL, DAL, Data Layer. Ever hear of an O/R Mapper? Maybe you should look into them. Why do these architecture diagrams exist? They come from people who have learned the hard way, studied how to build enterprise
applications, and gone to school for years learning how to do so. Some of us have done it the wrong way long enough that we finally had a nervous breakdown, sh*t our pants, picked up the pieces, and learned the correct way of doing things. >>just that I should
do it because everyone else does it. Wrong. Most people don't do it the right way, that's why we're in business. Some try, a lot don't even know what the right way is. And amongst those that think they know the right way, there are many that sadly don't. And
then amongst those that do know the virtuous high road, and choose to follow it, there are indeed still differing methodologies and best-practice scenarios, based on the solution, and in some cases, personal preference. Good luck.
Thank you, I appreciate your conviction. I understand the 3-tier, n-tier methodoligies and the idea of separating logical functions with physical and logical boundaries. But unless you can tell me our site will perform better I don't see a need to make my code
more abstract for the sake of abstraction. I am worth my "salt" and this is the way I did it. This is a 70k+ visitor/month site for a $130MM multi-national, I'm not exactly a beginner. I do have a UI, a BLL, and a DAL - my implementation is only a little different
than most people and the layers overlap in places. The application diagrams you speak of never specify one implementation over another. I think you're just use to compiling everything all the time and you're not thinking outside the box. Seriously think about
it, why not do it this way? That question begs an objective response, not a "just because" college-trained broken record response. And what exactly is not reusable about a user control? Wherever I want to use it I plop it in with a line of code, same as importing
a namespace, only when I change the code I don't have to recompile everything. If anyone wants training on this (apparently) innovative new approach, let me know =) It's great for web apps (still waiting for sound, concrete reasons why not).
One more short reply: If there is no markup at all in a ascx file, then it is not a part of the UI. UI requires markup. Putting class definitions in a .ascx file vs. a .dll file only differs in one way: a .dll file requires compilation before deployment, a
.ascx file does not. Otherwise they are both compiled by the .NET framework into exactly the same IL symantics at run time.
A user control is not well suited to reusability because if you need the same functionality in another project you have to copy all the code over. If you find a bug in one copy, then you will need to go to everywhere it is re-used to update the code. Also,
this code is re-compiled everytime the ASPNet worker process is restarted or when the cache is flushed. ASPNet worker process is generally restarted once a day (I believe every 23 hours or thereabouts) and the cache is typically flushed whenever all sessions
have timed out (not a problem in a high volume site where visitors are on 24x7). The bottom line is that I think you are using user controls in a manner for which they are not optimized. That is not to say they don't/won't work, just that there are better
alternatives.
>>If anyone wants training on this (apparently) innovative new approach Unfortunately, I would have to replace the word innovative with "awkward". Frankly, if you're doing this all inline like it sounds, you're probably wasting a lot of your own time, as well
as taking a performance hit. All inline files get JIT compiled, placing a bunch of compiled assemblies in your temporary asp.net files directory. If you use codebehind, you get one logical dll that contains all the executable code, thereby providing an increase
in execution efficiency, not to mention all the other benefits. >>This is a 70k+ visitor/month site for a $130MM multi-national, I'm not exactly a beginner I know a guy who's been doing carpentry for 30 years. He's not a beginner. But he only makes about 10
bucks an hour because he isn't very good. In other words, this doesn't mean anything to me. I've met plenty of people who make 6 figures doing development and don't have a clue as to what they're doing. I'm not saying that you're one of those people, but what
I'm telling you is the truth, at least from what I've seen. >>But unless you can tell me our site will perform better I don't see a need to make my >>code more abstract for the sake of abstraction Then how about for the sake of maintenance, documentation,
re-usability OUTSIDE of a web application? If you use an illogical design, it's going to be hard for people who are (hopefully) going to look at the solution from a logical perspective. I'd rather have a more elegant design than something only I can understand.
ryedin3
Member
185 Points
37 Posts
Crude Web Matrix Architecture (review request)
Jun 17, 2004 07:25 PM|LINK
JOAC
Participant
1880 Points
376 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 01:03 AM|LINK
ryedin3
Member
185 Points
37 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 01:29 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 03:53 PM|LINK
Systems Architect
ryedin3
Member
185 Points
37 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 04:48 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 05:42 PM|LINK
Systems Architect
ryedin3
Member
185 Points
37 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 06:53 PM|LINK
ryedin3
Member
185 Points
37 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 07:06 PM|LINK
jbrinkman
Star
9822 Points
1963 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 07:35 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: Crude Web Matrix Architecture (review request)
Jun 18, 2004 07:39 PM|LINK
Systems Architect