Вопросы Теги

DAL и BLL в.NET

Похоже, вы звоните на боковую панель после основной части сообщения / страницы. Позвоните, прежде чем он появится на левой стороне. 

/**
* The Template for displaying single opporunities posts.
*
*/

get_header();
global $accesspresslite_options, $post;
$accesspresslite_settings = get_option( 'accesspresslite_options', 
$accesspresslite_options );
$post_class = get_post_meta( $post -> ID, 'accesspresslite_sidebar_layout', true );
 ?>

<div class="ak-container">
<?php 
    if ($post_class=='both-sidebar') { ?>
        <div id="primary-wrap" class="clearfix"> 
    <?php }
     get_sidebar('left'); 
?>
<div id="primary" class="content-area">
    <main id="main" class="site-main" role="main">


  <?php while ( have_posts() ) : the_post(); ?>

        <?php get_template_part( 'content', 'single' ); ?>

        <?php // accesspresslite_post_nav(); ?>

        <?php
        // If comments are open or we have at least one comment, load up the comment template
        if ( comments_open() || '0' != get_comments_number() ) :
            comments_template();
        endif;
        ?>

    <?php endwhile; // end of the loop. 

        ?>

    </main><!-- #main -->
</div><!-- #primary -->

    <?php 

    if ($post_class=='both-sidebar') { ?>
        </div> 
    <?php }

?>

10
задан driAn 17 January 2009 в 10:56
поделиться

2 ответа

профессионалы:
- простой подход и часть отображения данных сделан для Вас с таблицей данных.
- предложения некоторые удобства для увольнения Выбора, Добавляют, Запросы на обновление и Запросы на удаление.
- могло бы подойти для очень простого дизайна с немногими таблицами.
- подходящий для non-self-referencing ER degigns или ER с немногими справочными таблицами и простыми/небольшими количествами соединениями
- подходящий, где простое хранилище данных требуется. т.е. где сложные идеи OO должны быть применены к "бизнес-объектам", этот шаблон сделал бы вещи более трудными.

недостатки:
- большие модели OO будут бороться в этом шаблоне
- сложные проекты ER со многими таблицами, сложные отношения или требования объекта OO не будут соответствовать этому шаблону. таблицы данных не оказывают много помощи для объекта в коде, запрашивающего как LINQ.
- большинство запросов должно быть записано вручную в SQL (это включает соединения). да, можно использовать разработчика запроса, но это не помогает многому.
- существует много дублирования кода в этом подходе. как в Вас запишет много методов CRUD в Ваших классах BLL (который также необходимо записать с нуля).

заключение: это действительно зависит от Ваших требований. если Ваша реализация является маленькой/простой затем, это могло бы быть хорошей идеей. но рост на небольшой идее будет труден с этим подходом. больше подхода OO настроит Вас намного лучше для рефакторинга/расширения позже. этот шаблон является также более старым/устаревшим. объект, запрашивающий IQueryable/LINQ, более популярен и станет более широким стандартом вскоре. я предложил бы переход u на борту этого фургона. это будет лучше для Вашей персональной разработки в конечном счете также.:D

некоторые ссылки:

9
ответ дан 3 December 2019 в 18:36
поделиться

Я полностью рекомендую НЕ ИСПОЛЬЗУЯ ТАБЛИЦЫ ДАННЫХ. Изучите домен управляемая реализация дизайна, что Ваша вся платформа будет работать с регулярными объектами, которые можно передать в Список <> или Queryable <>. DataTables являются мусором, который не должен даже больше включаться в.NET.

Я также рекомендовал бы изучить использование Внедрения зависимости / Инверсия платформы Управления такая Microsoft Unity или StructureMap для создания слабо связанного кода.

12
ответ дан 3 December 2019 в 18:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: